Install Issue

Support for HandBrake on Linux, Solaris, and other Unix-like platforms
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
blenderfish
Posts: 3
Joined: Sun Oct 14, 2007 4:11 pm

Install Issue

Post by blenderfish »

Forgive the Noob question, but I am having trouble installing on Linux. I downloaded the Tarball for the Linux CLI, and unpacked it to a directory. I navigate to that directory, which shows a single executable file called Handbrake CLI. There is no Configure script, and running Make tells me that there is nothing to be done. I cannot run HandbrakeCLI directly. What am I missing?
User avatar
s55
HandBrake Team
Posts: 10347
Joined: Sun Dec 24, 2006 1:05 pm

Post by s55 »

You downloaded the binary, not the source code ....
redraiderbum
Enlightened
Posts: 132
Joined: Thu Jun 21, 2007 3:53 am

Post by redraiderbum »

If you want to compile do this:

http://handbrake.m0k.org/trac/wiki/CompileGuide

For linux, just go to the bottom where it says, "Check out the source code and build it". It's all there.

If you don't want to compile, just change the properties of that file you already have so it is able to execute. So all you have to do is right click on the HandbrakeCLI, go to properties, then to the permissions tab, then check the box that says something about allowing the program to execute.

If you want it to be accessible from anywhere in the file system, copy that file to your bin. Depending on which distro you are using, your bin may be in "/bin/", "/usr/bin/", or "/home/your_directory/bin/".
th3rmite
Posts: 27
Joined: Sun Sep 16, 2007 6:27 pm

Post by th3rmite »

@sr55: Is there any reason there aren't .deb or .rpm package installs? Its not too hard to do and I could make them if anyone was interested.
sr55 wrote:You downloaded the binary, not the source code ....
blenderfish
Posts: 3
Joined: Sun Oct 14, 2007 4:11 pm

Post by blenderfish »

Thanks for the replies guys. redraiderbum definitely nailed it for me.

Is there a reason that there is no .deb or RPM? For the newbies like me, it really helps to have packages and repositories.

Thanks again!
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

blenderfish wrote:Is there a reason that there is no .deb or RPM?
Because every time someone's volunteered to maintain one, they disappear after a few months, leaving archaic packages strewn across the net?
redraiderbum
Enlightened
Posts: 132
Joined: Thu Jun 21, 2007 3:53 am

Post by redraiderbum »

It seems like it may be a good idea. But considering that handbrake has no dependencies it might be superfluous. It would be cool to role it so that it installed to the system all the codecs that it uses. Then it wouldn't be necessary to install all the restricted codecs from various repo's. Libdvdcss is often a pain for me for more obscure distros.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

redraiderbum wrote:It would be cool to role it so that it installed to the system all the codecs that it uses.
Bad idea, imo. HB doesn't always use the latest libs. It uses ones everyone's sure works. But if you start installing those versions at system level, eventually you'll need to update one to get some other app to build, that doesn't include its own dependencies. And then the next time you try to build HB, there could be conflicts.
eddyg
Veteran User
Posts: 798
Joined: Mon Apr 23, 2007 3:34 am

Post by eddyg »

HB also patches the libs, which means that those libs have to be at specific revision levels. If we update the libs we go though a cycle of testing before releasing that version of the lib.

So, no, HB will always have to compile against its own version of the libs rather than the systems.

Cheers, Ed.
redraiderbum
Enlightened
Posts: 132
Joined: Thu Jun 21, 2007 3:53 am

Post by redraiderbum »

Yeah that's a bummer, it certainly would make the package lighter.
HB also patches the libs, which means that those libs have to be at specific revision levels. If we update the libs we go though a cycle of testing before releasing that version of the lib.
Out of curiosity, even if it is patched at specific revisions, only the release version would be rolled into an rpm, deb, port, or whatever. So all that would be required is that in the repo's there exists the version of the particular lib that is needed and it is linked as a dependency in the package. It seems like it would actually be essentially the same thing that is already done, except that all those dependent codecs wouldn't be hanging out in the handbrake package (presumably making it a lot lighter), each and every one would just sit in the repo and be linked as necessary. It would be simple to revert to older codecs this way.

If it were done that way, it would be possible to add and remove codec support as desired. Some hardcore linux users, for instance, don't like having any proprietary codecs on their computers at all... I admit they are crazy, but the fact remains. It just makes the whole thing more modular, like TMPGEnc for windows uses codecs as plugins rather than built in so users are free to use whatever version of the codec suits their needs.

Admittedly linux is farthest from the typical handbrake user so that would be a lot of work for little use, plus handbrake may have to have its own repo for this to work... I'm all talk, I know.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

redraiderbum wrote:So all that would be required is that in the repo's there exists the version of the particular lib that is needed and it is linked as a dependency in the package.
Which is a pretty big if, and not one anyone here has any control over.
It just makes the whole thing more modular, like TMPGEnc for windows uses codecs as plugins rather than built in so users are free to use whatever version of the codec suits their needs.
Except HandBrake is about ease of use and not emulating Windows design choices. Regular people do not enjoy hunting down codec packs.

You want to add a serious load of complexity to the app in order to please an exceedingly small segment of the userbase, so I really hope you're planning on doing all the heavy lifting yourself. This would require an immense amount of work, wouldn't it? To co-ordinate everything with the packaging system so that HandBrake's patches are applied to its dependencies as they're built, and to avoid conflicts with other apps. Not to mention all the core lib and cli code that'd have to test for what components are installed and change available options to suit. And you're planning on rewriting the jam and make files too?

Download Stats for 0.9.1 in declining order of popularity:

* MacGUI: 160616
* WinGUI: 80919
* WinCLI: 16744
* MacCLI: 11773
* LinuxCLI: 2951
* Source : 2190
-----------------------
Total: 275193

So let's be really generous and assume all those people downloading the source were Linux users. That's 5,141 people. That's not even 2% of the user base....and even if an easy packaging system increased the number of Linux users by 1000%, they'd still be running a very, very distant third to the Windows users, who *themselves* are a neglected minority of the userbase.

Also, you're assuming contrib APIs never change, and that is not true at all. You can't just flit back and forth between older and newer versions of libraries all the time. No one here has any control over the application interfaces for the 3rd party contribs, and it's a rare open source project that promises the way you interact with them will never change. And making it compatible with one way almost always means making it incompatible with the other. Like, say, when variable names and types change.
redraiderbum
Enlightened
Posts: 132
Joined: Thu Jun 21, 2007 3:53 am

Post by redraiderbum »

I agree completely.

I was thinking of less than complete modularity
Except HandBrake is about ease of use and not emulating Windows design choices. Regular people do not enjoy hunting down codec packs.
I don't either, that's actually the thing it could avoid. I honestly have no idea how the windows version works, but I was thinking of something similar to an update/revert repo. And I was thinking of it for windows, mac, and linux. If you run your own (which is again, maybe more work than it is worth), similar to the svn, but have a release branch and dev branch. Then you can approve codec packs and apply patches without requiring a new release. It also gives you control over the package names, variables and those types of problems that arise in the general purpuse repo's.

The only good reason I can think of to do this, is as the user base grows and more functionality keeps being added, it seems inevitable that bugs will arise in the 3rd party contributions and conflicts. It allows a mechanism for patching and updating... it would help with situations like releasing 0.9.0 then quickly following with 0.9.1. I assume the server load goes up when a new release drops, so if 0.9.1 was quietly patched to fix the problems then people wouldn't have to inundate the download server.

That's a LOT of downloads, I didn't realize it was so huge. Thank god the code is really stable or support would be a huge nightmare.
Post Reply