On Thu, 2008-03-13 at 10:15 -0400, Caleb Tennis wrote: > > +1 on that and if people who use binary pkgs don't tell us what breaks, > > we won't know. > > 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.
Please... God... no... > 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. As much as I hate to say it, your example was rather bunk, because openssl changed SONAME during that time. Keeping the package information isn't *nearly* as important and doing some checking on the package. It sounds more like we need to keep some additional information around, so checks on things like NEEDED can be done. Perhaps some new "LIBRARIES" file which lists libraries installed by the package. Then, prior to merge, $package_manager could check NEEDED versus RDEPEND versus LIBRARIES and bail if something's not right/missing. In this case, even if the RDEPEND was >=dev-libs/openssl-0.9.7 and you have 0.9.8, it would fail because NEEDED would list libssl.so.0.9.7, but LIBRARIES would only have libssl.so.0.9.8 in it. > 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. Uhh... >= in RDEPEND does that, already... Also, this wouldn't have resolved your openssl issue, at all. Your machine scenario above would have still failed, since the minimum version was 0.9.7 on your build host. > 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. Well, I sincerely hope that you do not file such a bug, as it would royally screw over the one team in Gentoo that *does* consistently use our binary package support. I would definitely like to see the support improved, but not at the expense of doing very stupid things like locking to specific versions/revisions of packages. No offense, but that screams of RPM hell. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer
signature.asc
Description: This is a digitally signed message part
