| 1 |
> +1 on that and if people who use binary pkgs don't tell us what breaks, |
| 2 |
> we won't know. |
| 3 |
|
| 4 |
I'll kick it off, then. |
| 5 |
|
| 6 |
The binpkg format needs some way to store the actual versions of the dependencies as |
| 7 |
they were on the machine the package was compiled on. Then, when emerging the |
| 8 |
binpkg, someway to force those dependencies on the new install machine would be |
| 9 |
nice. |
| 10 |
|
| 11 |
I'll give an example. Package A was built on machine 1, and has a dep on |
| 12 |
>=openssl-0.9.7. Machine 1 has openssl-0.9.8 already installed. Binary package |
| 13 |
built, no problem. |
| 14 |
|
| 15 |
Now, we attempt to install binary package A on machine 2, which has openssl-0.9.7. |
| 16 |
It installs fine, deps met. But, whoops, there's some symbols missing when we go to |
| 17 |
use package A on machine 2. After some time, we finally realize it's because we |
| 18 |
need new openssl. |
| 19 |
|
| 20 |
I use this example because it's actually hit me before, but it extends to lots of |
| 21 |
other scenarios. The obvious fix is to either use --deep, or just make sure you |
| 22 |
need machine 2 up to date with machine 1, though that's difficult to do when you're |
| 23 |
talking about machine 301 and machine 559. |
| 24 |
|
| 25 |
If there was a way to tell the bin package installer to make sure you met all of the |
| 26 |
same minimum verisons of the deps as they were on the original compiling machine, |
| 27 |
that would be fantastic. |
| 28 |
|
| 29 |
Now, I'm happy to file a bug and assign it (to the portage team?), but I view this |
| 30 |
really as a wishlist item, and since admittedly very few devs use the binpkg stuff, |
| 31 |
I didn't see it as something that would probably get acted upon anyway. I'm not |
| 32 |
complaining about that either, just merely stating a fact. |
| 33 |
|
| 34 |
Caleb |
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-dev@l.g.o mailing list |
Archives