| 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 |
Archives