Install Issue
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.
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.
-
- Posts: 3
- Joined: Sun Oct 14, 2007 4:11 pm
Install Issue
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?
-
- Enlightened
- Posts: 132
- Joined: Thu Jun 21, 2007 3:53 am
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/".
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/".
-
- Posts: 3
- Joined: Sun Oct 14, 2007 4:11 pm
-
- Enlightened
- Posts: 132
- Joined: Thu Jun 21, 2007 3:53 am
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.
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.redraiderbum wrote:It would be cool to role it so that it installed to the system all the codecs that it uses.
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.
So, no, HB will always have to compile against its own version of the libs rather than the systems.
Cheers, Ed.
-
- Enlightened
- Posts: 132
- Joined: Thu Jun 21, 2007 3:53 am
Yeah that's a bummer, it certainly would make the package lighter.
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.
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.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.
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.
Which is a pretty big if, and not one anyone here has any control over.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.
Except HandBrake is about ease of use and not emulating Windows design choices. Regular people do not enjoy hunting down codec packs.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.
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.
-
- Enlightened
- Posts: 132
- Joined: Thu Jun 21, 2007 3:53 am
I agree completely.
I was thinking of less than complete modularity
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.
I was thinking of less than complete modularity
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.Except HandBrake is about ease of use and not emulating Windows design choices. Regular people do not enjoy hunting down codec packs.
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.