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