(I experimented with binpkgs a little while ago in Prefix) On 13-03-2008 10:15:33 -0400, Caleb Tennis wrote: > > +1 on that and if people who use binary pkgs don't tell us what breaks, > > we won't know. > > I'll kick it off, then. > > The binpkg format needs some way to store the actual versions of the > dependencies as they were on the machine the package was compiled on. > Then, when emerging the binpkg, someway to force those dependencies on > the new install machine would be nice. > > I'll give an example. Package A was built on machine 1, and has a dep on > >=openssl-0.9.7. Machine 1 has openssl-0.9.8 already installed. Binary > >package > built, no problem. > > Now, we attempt to install binary package A on machine 2, which has > openssl-0.9.7. It installs fine, deps met. But, whoops, there's some > symbols missing when we go to use package A on machine 2. After some > time, we finally realize it's because we need new openssl.
Isn't that stored in the NEEDED file? > I use this example because it's actually hit me before, but it extends > to lots of other scenarios. The obvious fix is to either use --deep, > or just make sure you need machine 2 up to date with machine 1, though > that's difficult to do when you're talking about machine 301 and > machine 559. > > If there was a way to tell the bin package installer to make sure you > met all of the same minimum verisons of the deps as they were on the > original compiling machine, that would be fantastic. I guess ideally the SLOTs should match, as for instance libpcre 7.5 and 7.6 work fine as long as libpcre.so.0 is there. (No guarantees) But even, for platforms that need libgcc_s.so.1, any gcc that provides it should be fine. Though luckily gcc is almost never in DEPEND/RDEPEND. > Now, I'm happy to file a bug and assign it (to the portage team?), but > I view this really as a wishlist item, and since admittedly very few > devs use the binpkg stuff, I didn't see it as something that would > probably get acted upon anyway. I'm not complaining about that > either, just merely stating a fact. I think binpkgs store more information than you think. It's just that Portage doesn't fully use it (yet). -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
