1 |
>> I use this example because it's actually hit me before, but it extends to lots of |
2 |
>> other scenarios. The obvious fix is to either use --deep, or just make sure you |
3 |
>> need machine 2 up to date with machine 1, though that's difficult to do when |
4 |
>> you're |
5 |
>> talking about machine 301 and machine 559. |
6 |
> |
7 |
> As much as I hate to say it, your example was rather bunk, because |
8 |
> openssl changed SONAME during that time. Keeping the package |
9 |
|
10 |
You're right here. After review, the problem was the difference between 0.9.8e and |
11 |
0.9.8g, the latter of which provided some form of newer symbol that wasn't in e. |
12 |
But the concept is the same. |
13 |
|
14 |
> information isn't *nearly* as important and doing some checking on the |
15 |
> package. It sounds more like we need to keep some additional |
16 |
> information around, so checks on things like NEEDED can be done. |
17 |
> Perhaps some new "LIBRARIES" file which lists libraries installed by the |
18 |
> package. Then, prior to merge, $package_manager could check NEEDED |
19 |
> versus RDEPEND versus LIBRARIES and bail if something's not |
20 |
> right/missing. In this case, even if the RDEPEND was |
21 |
>>=dev-libs/openssl-0.9.7 and you have 0.9.8, it would fail because |
22 |
> NEEDED would list libssl.so.0.9.7, but LIBRARIES would only have |
23 |
> libssl.so.0.9.8 in it. |
24 |
|
25 |
This seems perfectly acceptable to me. |
26 |
|
27 |
> Uhh... >= in RDEPEND does that, already... Also, this wouldn't have |
28 |
> resolved your openssl issue, at all. Your machine scenario above would |
29 |
> have still failed, since the minimum version was 0.9.7 on your build |
30 |
> host. |
31 |
|
32 |
I'm not talking about meeting the minimum required by the ebuild, I'm talking about |
33 |
the minimum that were installed at the time of the emerge. |
34 |
|
35 |
> Well, I sincerely hope that you do not file such a bug, as it would |
36 |
> royally screw over the one team in Gentoo that *does* consistently use |
37 |
> our binary package support. |
38 |
|
39 |
I don't plan on filing the bug, but if it was an optional emerge option to use the |
40 |
actual version deps vs. the DEPEND of the ebuild, it wouldn't affect you would it? |
41 |
|
42 |
> I would definitely like to see the support improved, but not at the |
43 |
> expense of doing very stupid things like locking to specific |
44 |
> versions/revisions of packages. No offense, but that screams of RPM |
45 |
> hell. |
46 |
|
47 |
I'm not trying to lock to any specific version. I'm trying to reproduce on machine |
48 |
2 the same state of packages that package A was compiled against on machine 1. And |
49 |
even make it optional to do so, via an emerge flag. |
50 |
|
51 |
|
52 |
-- |
53 |
gentoo-dev@l.g.o mailing list |