1 |
On Thursday 15 of July 2010 12:14:29 Duncan wrote: |
2 |
> Gilles Dartiguelongue posted on Thu, 15 Jul 2010 11:09:39 +0200 as |
3 |
> |
4 |
> excerpted: |
5 |
> > Le jeudi 15 juillet 2010 à 09:49 +0100, Mike Auty a écrit : [...] |
6 |
> > |
7 |
> >> I can live with this for in places where it causes massive breakage |
8 |
> >> (openssl/libpng/libjpg), because it's genuinely useful, but I think it |
9 |
> >> should be restricted to such important packages, or at least disabled |
10 |
> >> by FEATURES="-preserve-libs". |
11 |
> >> |
12 |
> >> Ideally, these calls should either adhere to FEATURES="-preserve-libs", |
13 |
> >> or there should be a tool that can identify which files portage has |
14 |
> >> preserved, and allow easy rebuilding of dependent packages, and |
15 |
> >> removal. |
16 |
> >> |
17 |
> >> At the moment, I'm having to manually grep ebuilds, ls the libraries |
18 |
> >> |
19 |
> >> and run revdep-rebuild over them one at a time... |
20 |
> > |
21 |
> > These sound like very good ideas to me. |
22 |
> |
23 |
> ++ |
24 |
> |
25 |
> If I have FEATURE=-preserve-libs, that's what I want. Exceptions should |
26 |
> be limited to what will break the toolchain (including revdep-rebuild |
27 |
> here, since that's what's normally used to get out of the situation) |
28 |
> itself. |
29 |
> |
30 |
> If there was a way to handle it so a general revdep-rebuild run would |
31 |
> still detect the preserved library as missing and do the necessary |
32 |
> rebuilds, it'd be one thing, but if the libraries are there, it figures |
33 |
> things are OK unless you've fed it that specific library, thereby making a |
34 |
> general revdep-rebuld run useless at the very task it was designed to fix. |
35 |
> |
36 |
> Talking about which... What about creating an eutils (or whatever) |
37 |
> function to handle the critical preservations, having it build a |
38 |
> centralized list of them somewhere, and having a revdep-rebuild mode that |
39 |
> will treat that list as if it had been fed in with --library on the |
40 |
> command line? Make revdep-rebuild able to run this mode either on its |
41 |
> own, or as part of an otherwise general run, and then you can have |
42 |
> packages (or the package-manager itself, if it uses the list as well) |
43 |
> preserve libs as they wish, without interfering with the ability of revdep- |
44 |
> rebuild to detect and resolve the issues in a normal run. |
45 |
|
46 |
And what about using portage 2.2 and be done with it. I don't see the point in |
47 |
reinventing the wheel yet again. |
48 |
|
49 |
Imho, revdep-rebuild and all 'misc' tools requiring users' good will like |
50 |
python-updater should be obsolete and phased out in favour of package manager |
51 |
controlled mechanisms. |
52 |
|
53 |
-- |
54 |
regards |
55 |
MM |