| 1 |
On Sat, Jul 23, 2005 at 01:20:19AM +0200, Sven Köhler wrote: |
| 2 |
> > Out of curiousity, has any put any thought into some automated method |
| 3 |
> > or hook for allowing restarting of rc-scripts on upgrade/re-emerge of |
| 4 |
> > a package? |
| 5 |
> > |
| 6 |
> > Other question is if any such hook is even needed. |
| 7 |
> > So... thoughts? I don't really have any input on it, aside from I'd |
| 8 |
> > like to gather what people want/think would be useful. |
| 9 |
> |
| 10 |
> Another good idea, would be "pending jobs" list. Many ebuilds provide |
| 11 |
> imports instructions like "you can now delete this or that config-file" |
| 12 |
> or like "you must immediatly run this or that". |
| 13 |
> |
| 14 |
> These usually scroll by while there're nobody watching the screen and/or |
| 15 |
> they cannot be read completely, since they scroll away too fast. |
| 16 |
logging (and post display) of info/warning, it's in head. |
| 17 |
|
| 18 |
> Apropos config-files: what about config-files that are provided by the |
| 19 |
> old-version of an ebuild but have been moved or removed by the new |
| 20 |
> version? etc-update doesn't know about them. So /etc/ will be full of |
| 21 |
> useless config-files after some time. |
| 22 |
Vapier had suggested yanking (on unmerge, not replacement) any |
| 23 |
config_protected file that has the same md5/mtime as what it was |
| 24 |
originally merged with. |
| 25 |
|
| 26 |
This would cause issues for nvidia-kernel though I'd think, although |
| 27 |
their solution isn't exactly optimal (no better solution atm either |
| 28 |
though). |
| 29 |
~harring |
Archives