FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 06-03-2011, 08:02 PM
Ville Skyttä
 
Default Systemd scriptlet comments

Some comments on systemd scriptlets at
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

1) I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts
and one does a version bump in the previous distro - the trigger in the
next one will no longer run on distro upgrades because of the
versioning. Wouldn't it work better to just drop the version from the
trigger altogether, and instead check if the old init script exists?
For example:

%triggerun -- httpd
[ -e %{_initddir}/httpd ] || exit 0
# rest of the migration stuff goes here

2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets,
only the final exit status of a script has any effect.

3) More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-20-2011, 06:29 PM
Ville Skyttä
 
Default Systemd scriptlet comments

On 06/03/2011 11:02 PM, Ville Skyttä wrote:
> Some comments on systemd scriptlets at
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

Ping? I think at least 1) below is important enough to be addressed
before wider systemd conversion starts to take place.

> 1) I don't think the versioned trigger logic will work too well at all
> in the (not that rare) cases where the previous distro had sysv scripts
> and one does a version bump in the previous distro - the trigger in the
> next one will no longer run on distro upgrades because of the
> versioning. Wouldn't it work better to just drop the version from the
> trigger altogether, and instead check if the old init script exists?
> For example:
>
> %triggerun -- httpd
> [ -e %{_initddir}/httpd ] || exit 0
> # rest of the migration stuff goes here
>
> 2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets,
> only the final exit status of a script has any effect.
>
> 3) More or less cosmetic: why hardwire absolute paths everywhere? The
> vast majority of other scriptlet snippets don't do that.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-22-2011, 04:24 PM
Toshio Kuratomi
 
Default Systemd scriptlet comments

On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
> Some comments on systemd scriptlets at
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
>
> 1) I don't think the versioned trigger logic will work too well at all
> in the (not that rare) cases where the previous distro had sysv scripts
> and one does a version bump in the previous distro - the trigger in the
> next one will no longer run on distro upgrades because of the
> versioning. Wouldn't it work better to just drop the version from the
> trigger altogether, and instead check if the old init script exists?
> For example:
>
> %triggerun -- httpd
> [ -e %{_initddir}/httpd ] || exit 0
> # rest of the migration stuff goes here
>
We discussed this when we came up with the guidelines. IIRC, we finally
decided this wasn't workable because we don't prevent people from packaging
systemVinit scripts (either in subpackages or in a wholly separate package.

I agree with your points about fragility, though. If you can think of a way
that handles both I'd be happy to hear it.

> 2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets,
> only the final exit status of a script has any effect.
>
<nod> I think I'll leave these alone as people don't always understand
that.

> 3) More or less cosmetic: why hardwire absolute paths everywhere? The
> vast majority of other scriptlet snippets don't do that.

I've replaced /usr/bin with %{_bindir} now. Are there other paths that we
could change?

Thanks, and sorry for taking so long to see this,
-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-24-2011, 10:37 AM
Ville Skyttä
 
Default Systemd scriptlet comments

On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
> On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
>> Some comments on systemd scriptlets at
>> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
>>
>> 1) I don't think the versioned trigger logic will work too well at all
>> in the (not that rare) cases where the previous distro had sysv scripts
>> and one does a version bump in the previous distro - the trigger in the
>> next one will no longer run on distro upgrades because of the
>> versioning. Wouldn't it work better to just drop the version from the
>> trigger altogether, and instead check if the old init script exists?
>> For example:
>>
>> %triggerun -- httpd
>> [ -e %{_initddir}/httpd ] || exit 0
>> # rest of the migration stuff goes here
>>
> We discussed this when we came up with the guidelines. IIRC, we finally
> decided this wasn't workable because we don't prevent people from packaging
> systemVinit scripts (either in subpackages or in a wholly separate package.
>
> I agree with your points about fragility, though. If you can think of a way
> that handles both I'd be happy to hear it.

Just a couple of unfiltered thoughts, reader beware; haven't spent much
thought or time on these yet:

a) If people do package/have sysv scripts alongside systemd ones, is it
desirable to make the systemd migration happen on upgrades in the first
place?

b) Maybe checking for existence of the systemd unit file in addition to
the sysv script in the above recipe could have some positive properties.

For the packages I migrate to systemd, I don't plan to keep any sysv
init scripts around, and the version bump problem would lurk out there
ready to bite if I used the currently documented scriptlets. So I'm
going to use the sysv script existence check way instead.

>> 3) More or less cosmetic: why hardwire absolute paths everywhere? The
>> vast majority of other scriptlet snippets don't do that.
>
> I've replaced /usr/bin with %{_bindir} now.

That removes the "hardwire" part for a few cases, but doesn't address
the "absolute" part.

> Are there other paths that we could change?

I'd personally remove all absolute paths to commands in standard PATH
from the scripts altogether where possible, macroized or not. The
Gconf, GSettings, gdk-pixbuf, GTK+ modules, GIO modules, Scrollkeeper,
desktop-database, mimeinfo, and Icon Cache scriptlets and macros are
already written without unnecessary absolute paths. The only ones that
do contain apparently unnecessary absolute paths are Systemd and
Texinfo. Why?
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-25-2011, 12:40 AM
Toshio Kuratomi
 
Default Systemd scriptlet comments

On Fri, Jun 24, 2011 at 01:37:02PM +0300, Ville Skyttä wrote:
> On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
> > On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
> >> Some comments on systemd scriptlets at
> >> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
> >>
> >> 1) I don't think the versioned trigger logic will work too well at all
> >> in the (not that rare) cases where the previous distro had sysv scripts
> >> and one does a version bump in the previous distro - the trigger in the
> >> next one will no longer run on distro upgrades because of the
> >> versioning. Wouldn't it work better to just drop the version from the
> >> trigger altogether, and instead check if the old init script exists?
> >> For example:
> >>
> >> %triggerun -- httpd
> >> [ -e %{_initddir}/httpd ] || exit 0
> >> # rest of the migration stuff goes here
> >>
> > We discussed this when we came up with the guidelines. IIRC, we finally
> > decided this wasn't workable because we don't prevent people from packaging
> > systemVinit scripts (either in subpackages or in a wholly separate package.
> >
> > I agree with your points about fragility, though. If you can think of a way
> > that handles both I'd be happy to hear it.
>
> Just a couple of unfiltered thoughts, reader beware; haven't spent much
> thought or time on these yet:
>
> a) If people do package/have sysv scripts alongside systemd ones, is it
> desirable to make the systemd migration happen on upgrades in the first
> place?
>
I'm not sure.... In earlier days when we had other init systems coexisting
alongside of sysvinit scripts, we were able to boot with
init=/sbin/other_init provided that we had "init scripts" for the services
we cared about for the other init system.

If that's still the case we're shooting for, then I think we do want to have
migration happen on upgrade.

> b) Maybe checking for existence of the systemd unit file in addition to
> the sysv script in the above recipe could have some positive properties.
>
I don't think this works.

Lets say you have:

foo-1.0-1 (sysv)
foo-1.0-2 (systemd)
sysvinit-basescripts-1.0 (which contains sysv init scripts for foo).

We want to perform migration when foo-1.0-2 (or later) replaces foo-1.0-1
but not if the init script is provided by sysvinit-basescripts. This
doesn't seem to be predictable based on presence or absence of systemv init
scripts and systemd unit files. It's ambiguous whether the presence of
a sysvinit script came from the foo-1.0-1 package and therefore means that
we're upgrading or if it came from the sysvinit-basescripts package and
therefore means we're trying to configure the system to boot with a sysv
init system.

> For the packages I migrate to systemd, I don't plan to keep any sysv
> init scripts around, and the version bump problem would lurk out there
> ready to bite if I used the currently documented scriptlets. So I'm
> going to use the sysv script existence check way instead.
>
Unfortunately, this isn't enough as someone providing init scripts for your
service in a separate package can ruin detection based on presence or
absence of the init script.

> >> 3) More or less cosmetic: why hardwire absolute paths everywhere? The
> >> vast majority of other scriptlet snippets don't do that.
> >
> > I've replaced /usr/bin with %{_bindir} now.
>
> That removes the "hardwire" part for a few cases, but doesn't address
> the "absolute" part.
>
> > Are there other paths that we could change?
>
> I'd personally remove all absolute paths to commands in standard PATH
> from the scripts altogether where possible, macroized or not. The
> Gconf, GSettings, gdk-pixbuf, GTK+ modules, GIO modules, Scrollkeeper,
> desktop-database, mimeinfo, and Icon Cache scriptlets and macros are
> already written without unnecessary absolute paths. The only ones that
> do contain apparently unnecessary absolute paths are Systemd and
> Texinfo. Why?
>
Ah I see -- I tend to agree but I don't know what the other packaging
committee members think so I've added it as a ticket for the next meeting:

https://fedorahosted.org/fpc/ticket/96

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-19-2011, 10:24 PM
Ville Skyttä
 
Default Systemd scriptlet comments

On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:

> We discussed this when we came up with the guidelines. IIRC, we finally
> decided this wasn't workable because we don't prevent people from packaging
> systemVinit scripts (either in subpackages or in a wholly separate package.
>
> I agree with your points about fragility, though. If you can think of a way
> that handles both I'd be happy to hear it.

Regarding the above, I don't think trying to chase "someone might do
something" at the expense of making regular package maintenance harder
or knowingly break at least to some extent is a good approach.

Anyway, here's a couple of new thoughts:

First, daemons are usually restarted on upgrade after the old package
has been removed, so if this is desirable and the trigger approach is
used, the try-restart should be done in %triggerpostun instead of
%triggerun, no?

Second, one way to ensure that the EVR of the package in the distro
version that had the sysv scripts stays older than the one in which
systemd migration happens even if the old distro version gets version
updates is to bump Epoch when doing the migration, and take advantage of
that in the versioned trigger.

Third, for my test case where the old package does its try-restart with
"service" instead of invoking the init script directly, this appears to
work fine:

%pre
if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] &&
[ -e %{_initddir}/FOO ] ; then
systemd-sysv-convert --save FOO &>/dev/null
chkconfig --del FOO &>/dev/null || :
fi

%post
systemctl daemon-reload &>/dev/null || :

%preun
if [ $1 -eq 0 ] ; then
systemctl --no-reload disable FOO.service &>/dev/null
systemctl stop FOO.service &>/dev/null || :
fi

%postun
systemctl daemon-reload &>/dev/null
[ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :

I believe the conditions in %pre should prevent it from doing bad things
(only when upgrading the package, and only if the sysv script is around
but the unit file isn't yet). Note that daemon-reload is done in %post
also for upgrades so that the "service FOO try-restart" in the old
package's %postun will do the right thing. Note also no need for
triggers in this scenario.

If the old package's %postun invokes the sysv init script directly,
getting the daemon restarted gets uglier but using a temp file (for
example
%{_var}/run/%{name}-%{version}-%{release}-%{arch}.systemd-migration,
referred to as %{migrfile} below), something like this works in my tests:

%pre
rm -f %{migrfile} &>/dev/null
if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] &&
[ -e %{_initddir}/FOO ] ; then
systemd-sysv-convert --save FOO &>/dev/null
chkconfig --del FOO &>/dev/null
touch %{migrfile} &>/dev/null
fi
exit 0

%post
[ $1 -eq 1 ] && systemctl daemon-reload &>/dev/null || :

%preun
if [ $1 -eq 0 ] ; then
systemctl --no-reload disable FOO.service &>/dev/null
systemctl stop FOO.service &>/dev/null || :
fi

%postun
systemctl daemon-reload &>/dev/null
[ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :

%triggerpostun -- %{name}
if [ $1 -gt 0 ] && [ -e %{migrfile} ] ; then
systemctl daemon-reload &>/dev/null
systemctl try-restart FOO.service &>/dev/null
fi
rm -f %{migrfile} &>/dev/null || :
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-20-2011, 03:03 PM
Toshio Kuratomi
 
Default Systemd scriptlet comments

Side note -- I can't convince you to serve on the FPC again can I? I've
been somewhat burnt out by the systemd guideline process and I have
a conflict with the Board meetings so I've been thinking of leaving the FPC.
But our crop of candidates whenever we've had to replace people has been
pretty slim and we haven't managed to pick up anyone recently that carries
list discussions back to FPC for consideration so I've been hesitant to do
so. If you have time and inclination to step back into an FPC role let me
know :-)

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-20-2011, 04:24 PM
Toshio Kuratomi
 
Default Systemd scriptlet comments

Sorry for sending private messages to the public list. I guess
that'll teach me not to send email while attending two meetings :-)

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-20-2011, 05:10 PM
Toshio Kuratomi
 
Default Systemd scriptlet comments

On Tue, Jul 19, 2011 at 3:24 PM, Ville Skyttä <ville.skytta@iki.fi> wrote:
> On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
>
>> We discussed this when we came up with the guidelines. *IIRC, we finally
>> decided this wasn't workable because we don't prevent people from packaging
>> systemVinit scripts (either in subpackages or in a wholly separate package.
>>
>> I agree with your points about fragility, though. *If you can think of a way
>> that handles both I'd be happy to hear it.
>
> Regarding the above, I don't think trying to chase "someone might do
> something" at the expense of making regular package maintenance harder
> or knowingly break at least to some extent is a good approach.
>
I agree about breakage. But I guess we are drawing different lines
regarding what's harder for regular package maintenance. One solution
might be to have two separate scriptlets, one if you're retaining the
sysv scripts and one if you aren't. OTOH, the systemd section is
already pretty long and conditionalized which doesn't make for easy
reading (perhaps it's inevitable when dealing with init; the SysV
section was also pretty long and involved).

> Anyway, here's a couple of new thoughts:
>
> First, daemons are usually restarted on upgrade after the old package
> has been removed, so if this is desirable and the trigger approach is
> used, the try-restart should be done in %triggerpostun instead of
> %triggerun, no?
>
Is the important part that the old package has been removed or that
the new package has been installed? If %triggerun is happening
sufficiently late, then using it allows us to only have on trigger
script rather than two. If it does make a difference, then you're
right, we should move the try-restart portion to its own
%triggerpostun.

> Second, one way to ensure that the EVR of the package in the distro
> version that had the sysv scripts stays older than the one in which
> systemd migration happens even if the old distro version gets version
> updates is to bump Epoch when doing the migration, and take advantage of
> that in the versioned trigger.
>
I thought of this but didn't think that anyone would go for it. I
think the argument against epoch has traditionally been that it's not
user-visible and it's easy for packagers to forget to update
dependencies when an epoch is in use.

> Third, for my test case where the old package does its try-restart with
> "service" instead of invoking the init script directly, this appears to
> work fine:
>
> * *%pre
> * *if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] &&
> * * * [ -e %{_initddir}/FOO ] ; then
> * * * *systemd-sysv-convert --save FOO &>/dev/null
> * * * *chkconfig --del FOO &>/dev/null || :
> * *fi
>
> * *%post
> * *systemctl daemon-reload &>/dev/null || :
>
> * *%preun
> * *if [ $1 -eq 0 ] ; then
> * * * *systemctl --no-reload disable FOO.service &>/dev/null
> * * * *systemctl stop FOO.service &>/dev/null || :
> * *fi
>
> * *%postun
> * *systemctl daemon-reload &>/dev/null
> * *[ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :
>
> I believe the conditions in %pre should prevent it from doing bad things
> (only when upgrading the package, and only if the sysv script is around
> but the unit file isn't yet). *Note that daemon-reload is done in %post
> also for upgrades so that the "service FOO try-restart" in the old
> package's %postun will do the right thing. *Note also no need for
> triggers in this scenario.
>
> If the old package's %postun invokes the sysv init script directly,
> getting the daemon restarted gets uglier but using a temp file (for
> example
> %{_var}/run/%{name}-%{version}-%{release}-%{arch}.systemd-migration,
> referred to as %{migrfile} below), something like this works in my tests:
>
> * *%pre
> * *rm -f %{migrfile} &>/dev/null
> * *if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] &&
> * * * [ -e %{_initddir}/FOO ] ; then
> * * * *systemd-sysv-convert --save FOO &>/dev/null
> * * * *chkconfig --del FOO &>/dev/null
> * * * *touch %{migrfile} &>/dev/null
> * *fi
> * *exit 0
>
> * *%post
> * *[ $1 -eq 1 ] && systemctl daemon-reload &>/dev/null || :
>
> * *%preun
> * *if [ $1 -eq 0 ] ; then
> * * * *systemctl --no-reload disable FOO.service &>/dev/null
> * * * *systemctl stop FOO.service &>/dev/null || :
> * *fi
>
> * *%postun
> * *systemctl daemon-reload &>/dev/null
> * *[ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :
>
> * *%triggerpostun -- %{name}
> * *if [ $1 -gt 0 ] && [ -e %{migrfile} ] ; then
> * * * *systemctl daemon-reload &>/dev/null
> * * * *systemctl try-restart FOO.service &>/dev/null
> * *fi
> * *rm -f %{migrfile} &>/dev/null || :

If you'd like to write this up as a draft I know that we beat
ourselves up trying to remove the need for triggers before giving up.
So we'd probably like to have something that does without them.
Documenting how and what you've tested would also be good as testing
these is one of the pain points when working on this.
(For instance, this set of tests [which even after doing all that,
still wasn't a complete set of tests] that I did prior to our
discarding migration of boot-on/off status:
https://fedoraproject.org/wiki/User:Toshio/Testing_systemd )

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-26-2011, 04:59 PM
Ville Skyttä
 
Default Systemd scriptlet comments

On 07/20/2011 06:03 PM, Toshio Kuratomi wrote:
> Side note -- I can't convince you to serve on the FPC again can I?

It's not out of the question some time in the future, but at least for
the coming few months I won't have enough time for that.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 04:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org