[gentoo-dev] upgrade's and rc-scripts

[gentoo-dev] upgrade's and rc-scripts

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

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.
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] upgrade's and rc-scripts

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Wed, 2005-07-20 at 16:54 -0500, Brian D. Harring 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.

Very very bad idea unless dispatch-conf or etc-update has been run...

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] upgrade's and rc-scripts

[Mike Frysinger]

On Wednesday 20 July 2005 05:54 pm, Brian D. Harring 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?

such a completely automated thing is a bad idea ... detecting and warning 
though isnt a bad idea ... too many issues such as config files may need to 
be upgraded or maybe a config file was edited but admin doesnt want to 
restart the service just yet, etc...

this probably falls under the pkg_{pre,post}inst gathering code bug ... but at 
the very end of an emerge process, i think that there should be a summary of 
packages which were upgraded and have a running init script ... detecting 
whether a given init script is running is trivial, just ask us base folk on 
irc and we can point you in the right direction
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] upgrade's and rc-scripts

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Wed, Jul 20, 2005 at 06:10:31PM -0400, Chris Gianelloni wrote:
> On Wed, 2005-07-20 at 16:54 -0500, Brian D. Harring 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.
> 
> Very very bad idea unless dispatch-conf or etc-update has been run...
Oh wow.  Total brain fart on that one...
Quite a valid point :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] upgrade's and rc-scripts

[Zac Medico]

Mike Frysinger wrote:
> On Wednesday 20 July 2005 05:54 pm, Brian D. Harring 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?
> 
> 
> such a completely automated thing is a bad idea ... detecting and warning 
> though isnt a bad idea ... too many issues such as config files may need to 
> be upgraded or maybe a config file was edited but admin doesnt want to 
> restart the service just yet, etc...
> 

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.

> this probably falls under the pkg_{pre,post}inst gathering code bug ... but at 
> the very end of an emerge process, i think that there should be a summary of 
> packages which were upgraded and have a running init script ... detecting 
> whether a given init script is running is trivial, just ask us base folk on 
> irc and we can point you in the right direction
> -mike

This feature could live happily alongside the other one.

Zac
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: upgrade's and rc-scripts

[Duncan]

Zac Medico posted <42DF90B1.9030806@gmail.com>, 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

Re: [gentoo-dev] Re: upgrade's and rc-scripts

[Zac Medico]

Duncan wrote:
> Zac Medico posted <42DF90B1.9030806@gmail.com>, 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: Re: upgrade's and rc-scripts

[Duncan]

Zac Medico posted <42E11632.8040606@gmail.com>, excerpted below,  on Fri,
22 Jul 2005 08:52:18 -0700:

> Duncan wrote:
>> Zac Medico posted <42DF90B1.9030806@gmail.com>, 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.

Indeed.  IMO it's one of those things that get labeled "bluesky" on the
various development roadmaps.  It'd be nice... some day... but it'd be far
more work than it's really worth, today.  Furthermore, it wouldn't be the
work of just one person, but many Gentoo developers... which wouldn't be
bad except for the fact that such would necessarily take away from the
limited time (of volunteers, mind you, so the time /is/ limited, to bits
and pieces "stolen" from "real life") available for other things, a
package or two more one might maintain were it not for the extra work
creating and maintaining the versions, adding yet another entire area of
possible bugs to the already ever growing bugzilla db.  It's a nice idea
-- except for all the other things that pursuing it will mean do not get
done.

That said, many of what we know as the packages we deal with daily today
were such "nice ideas" at some point.  The trick is finding someone who is
sufficiently motivated by this challenge that they put more into it than
they'd put into other projects.  It's not quite the zero sum game the
above paragraph assumes.  Find someone (or several someones) sufficiently
interested, and it grows the pie.  One only has to look at the fantastic
and ever growing array of fine packages we have today to realize how true
that is, how big the pie is, only because one of the strengths of open
source is finding those folks and getting them interested, while at the
same time letting them "stand on the shoulders of giants."  Really, I
believe that's why stuff like Gentoo/FBSD and Gentoo on XBox project, and
others, don't get shot down.  Everyone realizes that while it might be
taking away perhaps 10-50% of the time invested from other things, the
other 50-90% is in many cases "growing the pie", investments that wouldn't
happen otherwise.  I've watched the Gentoo/FBSD project grow from an
initial enquiry, and know even as it takes a bit of time from the "Gentoo
core" by some, it is just as certainly making Gentoo as a whole more
robust, strengthening it in only the way adapting it for other platforms
can do.  The total *IS* really more than the sum of the parts, or neither
the FLOSS community in general nor Gentoo in particular would be where it
is today.  Thus, if someone's really driven to work on a project, than by
all means...

Anyway, yes, it's an interesting idea.  I hadn't thought of config
versioning in quite that way, before, tho I'm sure it's not an entirely
new concept (witness the ebuild format versioning so recently discussed,
and the versions of such things as the MIME format in the RFCs, before
that).  If it stimulates someone with the skills to get into it, where
they wouldn't have spent the time otherwise, enlarging that pie, that's a
GOOD thing, and there are enough reading this list/group that it's
certainly possible.   However, IMO, if it is to be done, ideally, it gets
done by new blood, or at least those sufficiently stimulated by the
prospect to devote significantly more time to it than they would have to
FLOSS or Gentoo otherwise, so it /is/ growing that pie, not splitting it
off into little segments.

FWIW...

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

[gentoo-dev] Re: upgrade's and rc-scripts

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] Re: upgrade's and rc-scripts

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: upgrade's and rc-scripts

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: upgrade's and rc-scripts

[Nathan L. Adams]

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

[gentoo-dev] Re: upgrade's and rc-scripts

[Enrico Horn]

Sven Köhler <skoehler <at> 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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]