| 1 |
Stuart Longland posted on Sun, 26 Jun 2011 22:27:40 +1000 as excerpted: |
| 2 |
|
| 3 |
> On 06/26/11 15:44, Benedikt Böhm wrote: |
| 4 |
>> On Sun, Jun 26, 2011 at 4:59 AM, Stuart Longland <redhatter@g.o> |
| 5 |
>> wrote: |
| 6 |
>>> - revdep-rebuild (handles packages broken by soname changes, etc) |
| 7 |
>> |
| 8 |
>> solved by preserved-libs in portage-2.2 |
| 9 |
> |
| 10 |
> Hmmm, except that portage-2.2 isn't stable yet... indeed it isn't even |
| 11 |
> out of alpha yet. Not going to unleash that on my production systems. |
| 12 |
|
| 13 |
Besides portage-2.2 still being unstable, preserved-libs "solves" the |
| 14 |
problem by keeping outdated, buggy and potentially security compromised |
| 15 |
libraries around. Further, it does so by artificially attaching old |
| 16 |
versions of various shared-object binaries to the new packages, thus |
| 17 |
producing a non-repeatable-build package, since what old versions get |
| 18 |
attached varies depending on what old versions were installed at the time. |
| 19 |
|
| 20 |
With obvious exceptions for the toolchain deps necessary to get out of |
| 21 |
the hole in the first place (which should in this view be kept to an |
| 22 |
absolute minimum), for some, that so-called "solution" is more broken |
| 23 |
than the problem it's trying to solve. For the people for whom it's a |
| 24 |
solution, great, it's a marvelous technical achievement I'm not |
| 25 |
detracting from, but for others, it's just a bigger problem. |
| 26 |
|
| 27 |
revdep-rebuild OTOH, has a more straightforward approach, simply |
| 28 |
detecting binaries that depended on now-absent libs and rebuilding them |
| 29 |
to depend on what's currently available instead. |
| 30 |
|
| 31 |
-- |
| 32 |
Duncan - List replies preferred. No HTML msgs. |
| 33 |
"Every nonfree program has a lord, a master -- |
| 34 |
and if you use the program, he is your master." Richard Stallman |
Archives