I’ve been meaning to write about this before, and since I was asked of something related by the Gechi I thought this was as good as a moment as it could be, for what concerns this topic. You probably all know that I run a tinderbox that is trying to ensure that the packages in Gentoo build, and work at least as intended. But as the description page says, the same name has been used by other projects, such as the official Infra one which provides logs, reverse dependency information, and binary packages for various architectures.
Given that, some people asked me before if I can provide binaries of the packages built by my tinderbox; the answer is “not a chance”, for a few reasons that are more complex than the average first glimpse would tell you. And it’s mostly beside the basic problem that Gentoo has very shabby support for binary packages, as both Fabio and Constanze could easily tell you.
In the set of problems, the issue at hands is licenses (and here the expert would probably be Matija as he’s quite interested in getting them right). Not only the tinderbox accept almost all the possible licenses that are available in Portage so that it can actually merge as many packages as are available, but it also does not turn the bindist USE flag on (which is used to make sure that the result is actually distributable; it disables feature that would link GPL-incompatible libraries into GPL software; it disables feature that are known patented and shouldn’t be used; it make sure that trademarks are respected — like Firefox). Both these issue make a good deal of generated binaries non-redistributable by themselves.
But that’s not all; even when the license would let me redistribute the binaries; copyleft licenses require me to redistribute the sources as well; just pointing at the Gentoo mirrors is not a good option there; I would have to provide all the downloaded and used distfiles, and all the ebuilds as used for build that binary. You might guess it’s not an easy task nor one that requires just a bit of online space.
Now, after you actually tackle all these issues, enabling the bindist USE flag, only accepting true opensource licenses that allow redistribution, and providing a way to publish all the sources together with the binaries, you’re still not set. The rest of the problems are actually technological ones, tied to the way my tinderboxing scripts are designed to work. Even without counting the fact that the flag combinations are so many that you have to limit to some sanity, actually building every package in the tree gives me a number of headaches, starting with a number of automagic dependencies which would make the binary packages unusable.
On a side note, I’ve been thinking for a while of getting a way to set up dependency verification to ensure that no automagic dependencies enter the ELF files at least; unfortunately this is not as straightforward as I’d like it to be. New-style virtuals mean that the dependency is hidden under a second layer of packages, which in turn would make it difficult to actually pinpoint the error conditions. Think of the PyCURL trouble that I pointed at a few weeks ago.
What would actually work to produce decently-working binary packages is the method that Patrick has been using for tinderboxing: build one by one each package with only its own detailed dependencies merged in. After all, this is the method that the Debian- and RPM-based distributions follow. This has the opposite side effect of maybe failing if an indirect (transitive) dependency is missing, which often happens with pkg-config, but at least you wouldn’t find automagic dependencies on the binary packages themselves.
And as I noted in passing above, there are a number of problems related directly with the way Portage manages binary packages by itself: it does not have a properly clean way to track actually needed dependencies (ABI-wise that is) – and let’s not even go about the tracking of python dependencies – and the format itself is not really flexible enough, which causes headaches when trying to deal with special features like file-based capabilities.
So, good luck if you want to provide public binhosts, myself I don’t have time nor will to even think about them, for the most part.
What do you make of the binary package manager used by Sabyon? I think it somehow overlay’s portage but doesn’t’ use the binhost feature. Do you know anything about this?
I certainly can’t answer about Sabayon. Maybe they do things like use the official Mozilla binary builds of Firefox. I can’t answer about other distributions, either. Who knows? They might make their own mistakes in terms of licenses.What I do know is that in Gentoo we have the freedom to build things as would like for our own systems. That’s one of the great glories of Gentoo, and I give my thanks to Diego and others who keep it running.That said, there is one aspect of Gentoo I wish would be more like Debian: Python. I cringe every time there’s a Python update which some package requires. It puts me in for a huge round of python-updater and revdep-rebuild. Really, I can’t understand why we have this situation. In Gentoo, Python is installed in slots, yet it seems that libraries of compiled Python code seem not to have a nice versioning system as in the sonames when compiling from “stodgy” languages like C or C++. Maybe this comes from Python’s philosopy, which strikes me as fostering a blithe disregard for safety. (See http://xkcd.org/409/)
The BINHOST idea that comes from GeCHI is a complete no-sense, please ignore it. GeCHI doesn’t have neither the space, neither the bandwitch to serve a BINHOST.The day Gentoo will provide a package manager with a working support for binary packages (and a decent profile that forces sane and not modifiable {c,cxx,ld}flags + USE) we can start to speak about BINHOSTS. Spending efforts now for a not working BINHOST is a complete wast of time (IMHO).
Mike → that’s one of the things I actually bother me more than I can possibly say without recurring to bad words. You can find a summary of that “on another post”:https://blog.flameeyes.eu/2… — and yes I agree, our Python support is utter crap as it is.equilibrium → agreed; then try to keep a closer look at your own members if you weren’t aware someone asked me about that.