>> 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
You're right here. After review, the problem was the difference between 0.9.8e and 0.9.8g, the latter of which provided some form of newer symbol that wasn't in e. But the concept is the same. > 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. This seems perfectly acceptable to me. > 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. I'm not talking about meeting the minimum required by the ebuild, I'm talking about the minimum that were installed at the time of the emerge. > 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 don't plan on filing the bug, but if it was an optional emerge option to use the actual version deps vs. the DEPEND of the ebuild, it wouldn't affect you would it? > 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. I'm not trying to lock to any specific version. I'm trying to reproduce on machine 2 the same state of packages that package A was compiled against on machine 1. And even make it optional to do so, via an emerge flag. -- gentoo-dev@lists.gentoo.org mailing list
