> +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. 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. 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. Caleb -- gentoo-dev@lists.gentoo.org mailing list
