The Chronicles of Dean - Part 16
by, 30-04-2010 at 05:50 PM (23549 Views)
Captains Log (sensually masculine and rather large), Fri 30 April 2010 5:10 PM
I found a page for putting Gentoo portage on my Mac. I was excited. Macports sucks when it comes to uninstalling a dependancy, reinstalling things, finding orphaned packages, finding things that need to be recompiled when libraries and other files move. Macports is pretty good, but it leaves a lot to be desired.
This is a new Gentoo portage, not the ancient one that had a lot of problems and is now abandoned, and the manual specifically mentions details for Snow Leopard in regards to choosing a 32 or 64 bit build directory.
It turns out that Gentoo on the Mac is currently worse than macports because the packages that I want aren't building. I'm currently doing it again, in a more desirable location as well because where you start is where the directory has to stay (bastards should put that at the top of the manual). The reason I'm doing it again is primarily because I liked having a bash that behaved like the bash I was used to on linux. The colours of the files are the same at the command line, and more importantly, if I forget a cli option I can put it at the end of the command, for example in mac:
ls Directory -l
thinks you're looking to list the contents of "Directory" and "-l", while a proper bash experience should realise that you just wanted to use the -l option and put it at the end. This has always pissed me off about OS X. There's probably a simpler way than bootstrapping a bunch of stuff, including a compiler, and building another bash, but I don't know what that simpler way is.
Another benefit I hope to look at is that Gentoo and Macports should be able to work together where things are broken, for example, because of the differances in the way the BSD and Linux ports of some programs have been done, command line options mean differant things, and Macport developers don't comb through 3000 line bash scripts to find all of this. On top of that, sometimes there's things that are just plain missing in Macports. An example of both of these things is the tovid script for converting from any playable format to DVD.
I know that no-one uses DVDs to burn movies anymore, and we all have old laptops with VGA cables hooked up to our big TV's, but I needed to make one for someone. I installed tovid from macports, but found that some of the command line options didn't jive so between looking at man pages on OS X and an ssh into a Linux box, I fixed everything. This is a huge script. Its like 3000 lines of bash. The script then hands off to python scripts. I found it odd that anyone would bother with 3000 lines of bash.
Long story short, some of the tools that are later called weren't installed as dependencies when I installed tovid through macports. Those tools, as it turned out, don't exist. It makes it pointless to even have tovid available in macports. I could have saved a lot of time by rebooting into my Linux install and doing it from there, where tovid does work.
What I'm getting at, is that now I can edit the ebuild dependancies... for example mplayer isn't building at the moment in Gentoo, and macports is lacking some tools. I know those tools will be available in Gentoo, so what isn't available in one system will likely be in the other. The idea in this case is that I'd be able to run tovid without leaving OS X by putting both macports and gentoo in my path, and editing the Portfiles and ebuilds so that I can get everything jiving correctly.
If you need help and you can find them, maybe you can hire The A-Team.
At the time of writing, I had to skip building make the first time and let apple's make do it. I couldn't build apple-gcc until after portage was built. I did it before the sync. Remembering from yesterday, there was a problem with python and get-text or docxml or xml something... something like that... one of these builds will fail. Its a circular redundancy. you need to emerge --oneshot --nodeps python then emerge python again to pull in all its dependencies which will include the offending ebuild. Somehow, I think I didn't run into this today though, and that I had already dealt with at the point I'm at right now, which is emerging the GCC that portage is going to be using after emerge -e system at the end of it all.
Also, I didn't have the troubles with make yesterday that I did today... actually now that I think of it, the solution ended up bieng to hit the enter key when it hangs. That I am having a different experience right now than I did yesterday suggests that the project is alive in its maintenance.
Portage on Mac, even if it sucks, is kind of exciting, especially when the notion is that it will probably gain support rather than the other way around, plus I'm pretty sure I'll have a working tovid tonight.