Re: [gentoo-dev] Re: upgrade's and rc-scripts
On Sunday 24 July 2005 15:25, Martin Schlemmer wrote: > On Fri, 2005-07-22 at 18:40 -0500, Brian D. Harring wrote: > > On Sat, Jul 23, 2005 at 01:20:19AM +0200, Sven Köhler wrote: > > > Apropos config-files: what about config-files that are provided by > > > the old-version of an ebuild but have been moved or removed by the > > > new version? etc-update doesn't know about them. So /etc/ will be > > > full of useless config-files after some time. > > > > Vapier had suggested yanking (on unmerge, not replacement) any > > config_protected file that has the same md5/mtime as what it was > > originally merged with. > > > > This would cause issues for nvidia-kernel though I'd think, although > > their solution isn't exactly optimal (no better solution atm either > > though). > > Not sure I'm on speed with why that would be bad for nvidia-kernel? If necessary a "touch /etc/myconfigfile" in pkg_postinst would force that the config file stays there. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpTFn94tJ80L.pgp Description: PGP signature
[gentoo-dev] Re: upgrade's and rc-scripts
Sven Köhler upb.de> writes: > Another good idea, would be "pending jobs" list. Many ebuilds provide > imports instructions like "you can now delete this or that config-file" > or like "you must immediatly run this or that". > > These usually scroll by while there're nobody watching the screen and/or > they cannot be read completely, since they scroll away too fast. > Did you ever look at enotice? (http://gentooexperimental.org/script/repo/show/14) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: upgrade's and rc-scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian D. Harring wrote: > Vapier had suggested yanking (on unmerge, not replacement) any > config_protected file that has the same md5/mtime as what it was > originally merged with. As and end-user, that would be mana from heaven. :) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC54/V2QTTR4CNEQARAlm5AJ0b9i6pwfN62FLn/rHNvrkCXDN8VACgnghT s3MyShSLliagonr06yE2M2Q= =QSzI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: upgrade's and rc-scripts
On Fri, 2005-07-22 at 18:40 -0500, Brian D. Harring wrote: > On Sat, Jul 23, 2005 at 01:20:19AM +0200, Sven Köhler wrote: > > Apropos config-files: what about config-files that are provided by the > > old-version of an ebuild but have been moved or removed by the new > > version? etc-update doesn't know about them. So /etc/ will be full of > > useless config-files after some time. > Vapier had suggested yanking (on unmerge, not replacement) any > config_protected file that has the same md5/mtime as what it was > originally merged with. > > This would cause issues for nvidia-kernel though I'd think, although > their solution isn't exactly optimal (no better solution atm either > though). Not sure I'm on speed with why that would be bad for nvidia-kernel? Regards, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: upgrade's and rc-scripts
On Sat, Jul 23, 2005 at 01:20:19AM +0200, Sven Köhler wrote: > > Out of curiousity, has any put any thought into some automated method > > or hook for allowing restarting of rc-scripts on upgrade/re-emerge of > > a package? > > > > Other question is if any such hook is even needed. > > So... thoughts? I don't really have any input on it, aside from I'd > > like to gather what people want/think would be useful. > > Another good idea, would be "pending jobs" list. Many ebuilds provide > imports instructions like "you can now delete this or that config-file" > or like "you must immediatly run this or that". > > These usually scroll by while there're nobody watching the screen and/or > they cannot be read completely, since they scroll away too fast. logging (and post display) of info/warning, it's in head. > Apropos config-files: what about config-files that are provided by the > old-version of an ebuild but have been moved or removed by the new > version? etc-update doesn't know about them. So /etc/ will be full of > useless config-files after some time. Vapier had suggested yanking (on unmerge, not replacement) any config_protected file that has the same md5/mtime as what it was originally merged with. This would cause issues for nvidia-kernel though I'd think, although their solution isn't exactly optimal (no better solution atm either though). ~harring pgpGI7KDmu7aL.pgp Description: PGP signature
[gentoo-dev] Re: upgrade's and rc-scripts
> Out of curiousity, has any put any thought into some automated method > or hook for allowing restarting of rc-scripts on upgrade/re-emerge of > a package? > > Other question is if any such hook is even needed. > So... thoughts? I don't really have any input on it, aside from I'd > like to gather what people want/think would be useful. Another good idea, would be "pending jobs" list. Many ebuilds provide imports instructions like "you can now delete this or that config-file" or like "you must immediatly run this or that". These usually scroll by while there're nobody watching the screen and/or they cannot be read completely, since they scroll away too fast. Apropos config-files: what about config-files that are provided by the old-version of an ebuild but have been moved or removed by the new version? etc-update doesn't know about them. So /etc/ will be full of useless config-files after some time. I'd consider automatic restarting a less important problem. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: upgrade's and rc-scripts
Duncan wrote: Zac Medico posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 21 Jul 2005 05:10:25 -0700: This could be an optional feature such as FEATURES="restartservices". The CONFIG_PROTECT functionality could remain as is. Portage could use a special ebuild variable to determine whether the previous and new ebuilds have compatible configuration file formats (similar to EAPI) and only restart the service if they are compatible. Interesting. Something like PKG_CONFIG_VER, individualized for each package. Portage would know not to restart the service between major versions, and would know it could if the version stayed the same. The question would be what to do for minor config version changes (which would equate to compatible in general, but with one or more changes). I'd say that should mean a safe restart as well. If it wouldn't be safe, and since the config version would be a Gentoo-only arbitrary number, I'd say make that a major version change. I mentioned this mostly just because the idea popped into my head and thought others might be interested ;-). Upon further inspection, it does seem like a "opening can of worms". I'm not sure that the benefits of this feature would justify the costs of implementing it. Zac -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: upgrade's and rc-scripts
Zac Medico posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 21 Jul 2005 05:10:25 -0700: > This could be an optional feature such as FEATURES="restartservices". The > CONFIG_PROTECT functionality could remain as is. Portage could use a > special ebuild variable to determine whether the previous and new ebuilds > have compatible configuration file formats (similar to EAPI) and only > restart the service if they are compatible. Interesting. Something like PKG_CONFIG_VER, individualized for each package. Portage would know not to restart the service between major versions, and would know it could if the version stayed the same. The question would be what to do for minor config version changes (which would equate to compatible in general, but with one or more changes). I'd say that should mean a safe restart as well. If it wouldn't be safe, and since the config version would be a Gentoo-only arbitrary number, I'd say make that a major version change. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
