Re: Systemd conversion versus updates in back Fedora branches
Kevin Kofler writes: > Tom Lane wrote: >> FWIW, I'm totally on board with the idea of not switching to systemd in >> F15 --- and even if I wanted to do that, it's pure luck that the problem >> doesn't apply to F14->F15 upgrades as well, where such an option is >> certainly not available. > F14 will be EOL in less than 2 months. So that problem will be gone then, > and the "just push the systemd migration to all supported releases" plan > would be sound then if only FESCo and/or FPC would approve it. It's certainly *not* sound, given that the current packaging guidelines mandate not auto-applying the user's previous choices about whether to auto-start daemons. Would you be happy if a routine "yum update" disabled your mail daemon? Or even just changed its configuration significantly, as is more than likely to happen in such a transition? (My daemons no longer pay any attention to /etc/sysconfig, for instance.) To make that work would require a complete redesign of the scriptlets, not just permission to back-port the existing F16 specfile entries. And it would require per-package testing that nobody has done, and that this maintainer for one is uninterested in doing. So as I said, I'm totally not interested in switching the F15 packages to systemd. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Tom Lane wrote: > FWIW, I'm totally on board with the idea of not switching to systemd in > F15 --- and even if I wanted to do that, it's pure luck that the problem > doesn't apply to F14->F15 upgrades as well, where such an option is > certainly not available. F14 will be EOL in less than 2 months. So that problem will be gone then, and the "just push the systemd migration to all supported releases" plan would be sound then if only FESCo and/or FPC would approve it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Jóhann B. Guðmundsson wrote: > Unless FESCO granted them exception this update might be pulled back It's too late, the update already went stable. (And FYI, the reason I didn't alert folks was that I also only noticed this when reading the notes for my stable updates.) Reverting things now will break much more stuff than keeping the change. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On Mon, Oct 24, 2011 at 07:56:59AM -0500, Richard Shaw wrote:
> On Sun, Oct 23, 2011 at 10:52 PM, Tom Lane wrote:
> > The current packaging guidelines require packages that update from sysv
> > init scripts to systemd scripts to provide conversion triggers that are
> > fired on the basis of an NVR comparison:
> > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript
> >
> > That is, we assume that we know that all releases with NVR < some-cutoff
> > use initscripts and all releases with NVR >= same-cutoff use systemd.
> > The comments in the above-linked page acknowledge that this means it's
> > impossible to upgrade the package to a newer upstream release in
> > pre-systemd Fedora branches. (You can't just move the cutoff value
> > forward, because then an upgrade in F16 or later will mistakenly re-fire
> > the update trigger.)
>
> I'm not sure if this was the best things to do but on the mythtv
> package on RPM Fusion I added an additional requirement for
> %triggerrun that the fedora release >= 16 by enclosing the whole
> scriptlet in a %if 0{?fedora}...%endif, which seemed to make sense as
> we're not supposed to change/convert within a release. I had to do
> this because the same EVR is used for all supported Fedora releases.
>
> Is there something wrong with this approach?
>
If by additional you mean instead of, that approach sounds acceptable
although I haven't spent as much time thinking about what caveats might
occur there as with the other proposals.
-Toshio
pgpWkREfnTfz5.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On Mon, Oct 24, 2011 at 06:49:04AM +, "Jóhann B. Guðmundsson" wrote: > On 10/24/2011 03:52 AM, Tom Lane wrote: > > I'm really getting to the point where that's a completely unacceptable > > restriction. I've already blown off one mysql bug-fix release in F15 > > because of this restriction, and I see they just released another one > > that I'll be unable to ship in F15 because the systemd guys failed to do > > their homework, and there are likely to be several more before F15 dies. > > Which failure is that supposed to be? > > The "systemd guys" are not the ones that came up with any kind > update/upgrade/packaging policy so you are probably speaking of > FPC/FESCO here. > > I think the general idea was that maintainer(s) open a ticket with FESCO > where they asked them to grant exception to the general rule and be > allowed to push unit files to the GA release should the need arise but > feel free to correct me if I'm wrong. > That isn't the intention and that's not the problem that Tom is referring to anyhow. He's talking about the fact that the current scriptlets hardcode NEVR's into the spec file. Which means if the spec file is updated on an earlier release is updated, the package in later releases also needs to be bumped. It's more maintainer work but not an impossible thing to work with. there's a proposal that hasn't reachecd draft stage that attempts to remedy that. Someone just needs to pick that proposal up and run the rest of the way to the finish. -Toshio pgpbFX3abdvrN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On Mon, Oct 24, 2011 at 09:48:47AM -0400, Tom Lane wrote: > drago01 writes: > > 2011/10/24 "J�hann B. Gu�mundsson" : > >> On 10/24/2011 05:42 AM, Kevin Kofler wrote: > >>> FWIW, what the tomcat6 maintainers did is that they just ignored the > >>> guideline which says that you cannot migrate to systemd in an update and > >>> pushed this update: > > >> Unless FESCO granted them exception this update might be pulled back > >> atleast that was the case with mdadm [1] if I can recall correctly. > > > If it works this might not be a good idea, going back and forth just > > causes more pain for users. > > FWIW, I'm totally on board with the idea of not switching to systemd in > F15 --- and even if I wanted to do that, it's pure luck that the problem > doesn't apply to F14->F15 upgrades as well, where such an option is > certainly not available. The reason F14 escapes the problem is that > we went to a new mysql major release series in F15, something that > happens maybe once every three years or so. (The last-minute upgrade to > postgresql 9.1.x in F16 is likewise the only reason why I'm not bitching > about this with respect to postgresql too. And I suspect a whole lot of > other packagers are up against similar issues, or will be if they take > back-branch maintenance seriously.) > > What I want is a packaging guideline that doesn't simply blow off > the problem of upgrading packages in pre-systemd branches. It's not > an acceptable restriction, and I'm astonished that anybody ever thought > it would be. > I know that you commented on Ville's proposal. Have you tried it? Does it work for you? You could look at finishing it off as a draft and putting it onto the Packaging Committee's agenda. -Toshio pgpHoVIq3iRFf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Tom Lane (t...@redhat.com) said: > FWIW, I'm totally on board with the idea of not switching to systemd in > F15 --- and even if I wanted to do that, it's pure luck that the problem > doesn't apply to F14->F15 upgrades as well, where such an option is > certainly not available. The reason F14 escapes the problem is that > we went to a new mysql major release series in F15, something that > happens maybe once every three years or so. (The last-minute upgrade to > postgresql 9.1.x in F16 is likewise the only reason why I'm not bitching > about this with respect to postgresql too. And I suspect a whole lot of > other packagers are up against similar issues, or will be if they take > back-branch maintenance seriously.) > > What I want is a packaging guideline that doesn't simply blow off > the problem of upgrading packages in pre-systemd branches. It's not > an acceptable restriction, and I'm astonished that anybody ever thought > it would be. Make the upgrade trigger idempotent enough to not cause changes if it triggers in a case where it didn't need to? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 05:26 PM, Remi Collet wrote: > Isn't epoch a solution ? Yes, but.. > .. > Yes, I know, epoch is evil... That's why everybody (including me) believes there is a better solution. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Le 24/10/2011 05:52, Tom Lane a écrit : > The current packaging guidelines require packages that update from sysv > init scripts to systemd scripts to provide conversion triggers that are > fired on the basis of an NVR comparison: Isn't epoch a solution ? Epoch: 0 for sysv initscript Epoch: 1 for systemd unit file With %triggerun -- foo < 1:0 Yes, I know, epoch is evil... Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 04:52 PM, Tom Lane wrote: > I'm not really seeing why this'd be a better approach than what I > suggested above. This isn't better in case we don't ship -sysvinit sub-package. This was meant as a general approach which should work even if a user has installed sysvinit scripts from a sub-package (not mysql case). > It requires more assumptions about the behavior of the > systemd-sysv-convert code than I'm comfortable with --- in particular, > that that subsystem still keeps information around after a conversion > has been completed. Yes, it's not perfect. But feasible from my pov. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Honza Horak writes: > On 10/24/2011 05:52 AM, Tom Lane wrote: >> The idea I have at the moment is to ignore the advice to check package >> version, and instead have the triggerun script check to see whether the >> mysql sysv initscript file is present. I wonder whether anyone else has >> dealt with this and has working scriptlets? > We can prevent the repeated trigger run by using "systemd-sysv-convert > --show" in the trigger, since systemd-sysv-convert only appends to > /var/lib/systemd/sysv-convert/database: I'm not really seeing why this'd be a better approach than what I suggested above. It requires more assumptions about the behavior of the systemd-sysv-convert code than I'm comfortable with --- in particular, that that subsystem still keeps information around after a conversion has been completed. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 05:52 AM, Tom Lane wrote: > The current packaging guidelines require packages that update from sysv > init scripts to systemd scripts to provide conversion triggers that are > fired on the basis of an NVR comparison: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript > > That is, we assume that we know that all releases with NVR< some-cutoff > use initscripts and all releases with NVR>= same-cutoff use systemd. > The comments in the above-linked page acknowledge that this means it's > impossible to upgrade the package to a newer upstream release in > pre-systemd Fedora branches. (You can't just move the cutoff value > forward, because then an upgrade in F16 or later will mistakenly re-fire > the update trigger.) > > I'm really getting to the point where that's a completely unacceptable > restriction. I've already blown off one mysql bug-fix release in F15 > because of this restriction, and I see they just released another one > that I'll be unable to ship in F15 because the systemd guys failed to do > their homework, and there are likely to be several more before F15 dies. > > The idea I have at the moment is to ignore the advice to check package > version, and instead have the triggerun script check to see whether the > mysql sysv initscript file is present. I wonder whether anyone else has > dealt with this and has working scriptlets? > > regards, tom lane It has been already discussed (see [1]) that it is possible to bump the NVR in %triggerun macro to be able to update packages even in older branches. However, I haven't seen any working solutions to prevent the trigger code to be executed again when upgrading from already systemd-enabled package (see [2]). IOW, if we found a way to prevent the trigger to run in already systemd-enabled package, it would be possible to update packages even in older branches. We just need to remember to bump the NVR in %triggerun, which can be annoying but maybe less pain-full than other solutions. We can prevent the repeated trigger run by using "systemd-sysv-convert --show" in the trigger, since systemd-sysv-convert only appends to /var/lib/systemd/sysv-convert/database: %triggerun -- httpd < 1.0-2 if not /usr/bin/systemd-sysv-convert --show httpd >/dev/null 2>&1 ; then /usr/bin/systemd-sysv-convert --save httpd >/dev/null 2>&1 ||: /sbin/chkconfig --del httpd >/dev/null 2>&1 || : /bin/systemctl try-restart apache-httpd.service >/dev/null 2>&1 || : fi I've tried it and seems to do the thing. Please, correct me if I missed something. [1] http://lists.fedoraproject.org/pipermail/devel/2011-July/154838.html [2] http://lists.fedoraproject.org/pipermail/devel/2011-July/154906.html Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
drago01 writes: > 2011/10/24 "Jóhann B. Guðmundsson" : >> On 10/24/2011 05:42 AM, Kevin Kofler wrote: >>> FWIW, what the tomcat6 maintainers did is that they just ignored the >>> guideline which says that you cannot migrate to systemd in an update and >>> pushed this update: >> Unless FESCO granted them exception this update might be pulled back >> atleast that was the case with mdadm [1] if I can recall correctly. > If it works this might not be a good idea, going back and forth just > causes more pain for users. FWIW, I'm totally on board with the idea of not switching to systemd in F15 --- and even if I wanted to do that, it's pure luck that the problem doesn't apply to F14->F15 upgrades as well, where such an option is certainly not available. The reason F14 escapes the problem is that we went to a new mysql major release series in F15, something that happens maybe once every three years or so. (The last-minute upgrade to postgresql 9.1.x in F16 is likewise the only reason why I'm not bitching about this with respect to postgresql too. And I suspect a whole lot of other packagers are up against similar issues, or will be if they take back-branch maintenance seriously.) What I want is a packaging guideline that doesn't simply blow off the problem of upgrading packages in pre-systemd branches. It's not an acceptable restriction, and I'm astonished that anybody ever thought it would be. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On Sun, Oct 23, 2011 at 10:52 PM, Tom Lane wrote:
> The current packaging guidelines require packages that update from sysv
> init scripts to systemd scripts to provide conversion triggers that are
> fired on the basis of an NVR comparison:
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript
>
> That is, we assume that we know that all releases with NVR < some-cutoff
> use initscripts and all releases with NVR >= same-cutoff use systemd.
> The comments in the above-linked page acknowledge that this means it's
> impossible to upgrade the package to a newer upstream release in
> pre-systemd Fedora branches. (You can't just move the cutoff value
> forward, because then an upgrade in F16 or later will mistakenly re-fire
> the update trigger.)
I'm not sure if this was the best things to do but on the mythtv
package on RPM Fusion I added an additional requirement for
%triggerrun that the fedora release >= 16 by enclosing the whole
scriptlet in a %if 0{?fedora}...%endif, which seemed to make sense as
we're not supposed to change/convert within a release. I had to do
this because the same EVR is used for all supported Fedora releases.
Is there something wrong with this approach?
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 04:52 AM, Tom Lane wrote: > The current packaging guidelines require packages that update from sysv > init scripts to systemd scripts to provide conversion triggers that are > fired on the basis of an NVR comparison: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript > > That is, we assume that we know that all releases with NVR< some-cutoff > use initscripts and all releases with NVR>= same-cutoff use systemd. > The comments in the above-linked page acknowledge that this means it's > impossible to upgrade the package to a newer upstream release in > pre-systemd Fedora branches. (You can't just move the cutoff value > forward, because then an upgrade in F16 or later will mistakenly re-fire > the update trigger.) > > I'm really getting to the point where that's a completely unacceptable > restriction. I've already blown off one mysql bug-fix release in F15 > because of this restriction, and I see they just released another one > that I'll be unable to ship in F15 because the systemd guys failed to do > their homework, and there are likely to be several more before F15 dies. > > The idea I have at the moment is to ignore the advice to check package > version, and instead have the triggerun script check to see whether the > mysql sysv initscript file is present. I wonder whether anyone else has > dealt with this and has working scriptlets? You might try Ville Skyttä's scriptlets that were discussed on the packaging list back in July and appeared to work satisfactorily in testing but that thread seems to have died just before the point at which updated guidelines could have been produced and adopted. http://lists.fedoraproject.org/pipermail/packaging/2011-July/007846.html Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
2011/10/24 "Jóhann B. Guðmundsson" : > On 10/24/2011 05:42 AM, Kevin Kofler wrote: >> FWIW, what the tomcat6 maintainers did is that they just ignored the >> guideline which says that you cannot migrate to systemd in an update and >> pushed this update: >> https://admin.fedoraproject.org/updates/FEDORA-2011-13456 >> (which is already in the stable updates). > > Unless FESCO granted them exception this update might be pulled back > atleast that was the case with mdadm [1] if I can recall correctly. If it works this might not be a good idea, going back and forth just causes more pain for users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 05:42 AM, Kevin Kofler wrote: > FWIW, what the tomcat6 maintainers did is that they just ignored the > guideline which says that you cannot migrate to systemd in an update and > pushed this update: > https://admin.fedoraproject.org/updates/FEDORA-2011-13456 > (which is already in the stable updates). Unless FESCO granted them exception this update might be pulled back atleast that was the case with mdadm [1] if I can recall correctly. "* Mon Jul 18 2011 Doug Ledford - 3.2.2-6 - Back out systemd changes from rawhide" JBG 1. http://koji.fedoraproject.org/koji/buildinfo?buildID=253381 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
On 10/24/2011 03:52 AM, Tom Lane wrote: > I'm really getting to the point where that's a completely unacceptable > restriction. I've already blown off one mysql bug-fix release in F15 > because of this restriction, and I see they just released another one > that I'll be unable to ship in F15 because the systemd guys failed to do > their homework, and there are likely to be several more before F15 dies. Which failure is that supposed to be? The "systemd guys" are not the ones that came up with any kind update/upgrade/packaging policy so you are probably speaking of FPC/FESCO here. I think the general idea was that maintainer(s) open a ticket with FESCO where they asked them to grant exception to the general rule and be allowed to push unit files to the GA release should the need arise but feel free to correct me if I'm wrong. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd conversion versus updates in back Fedora branches
Tom Lane wrote: > The current packaging guidelines require packages that update from sysv > init scripts to systemd scripts to provide conversion triggers that are > fired on the basis of an NVR comparison: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript > > That is, we assume that we know that all releases with NVR < some-cutoff > use initscripts and all releases with NVR >= same-cutoff use systemd. > The comments in the above-linked page acknowledge that this means it's > impossible to upgrade the package to a newer upstream release in > pre-systemd Fedora branches. (You can't just move the cutoff value > forward, because then an upgrade in F16 or later will mistakenly re-fire > the update trigger.) > > I'm really getting to the point where that's a completely unacceptable > restriction. I've already blown off one mysql bug-fix release in F15 > because of this restriction, and I see they just released another one > that I'll be unable to ship in F15 because the systemd guys failed to do > their homework, and there are likely to be several more before F15 dies. > > The idea I have at the moment is to ignore the advice to check package > version, and instead have the triggerun script check to see whether the > mysql sysv initscript file is present. I wonder whether anyone else has > dealt with this and has working scriptlets? FWIW, what the tomcat6 maintainers did is that they just ignored the guideline which says that you cannot migrate to systemd in an update and pushed this update: https://admin.fedoraproject.org/updates/FEDORA-2011-13456 (which is already in the stable updates). I'm starting to wonder whether that wouldn't be the best solution here. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Systemd conversion versus updates in back Fedora branches
The current packaging guidelines require packages that update from sysv init scripts to systemd scripts to provide conversion triggers that are fired on the basis of an NVR comparison: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript That is, we assume that we know that all releases with NVR < some-cutoff use initscripts and all releases with NVR >= same-cutoff use systemd. The comments in the above-linked page acknowledge that this means it's impossible to upgrade the package to a newer upstream release in pre-systemd Fedora branches. (You can't just move the cutoff value forward, because then an upgrade in F16 or later will mistakenly re-fire the update trigger.) I'm really getting to the point where that's a completely unacceptable restriction. I've already blown off one mysql bug-fix release in F15 because of this restriction, and I see they just released another one that I'll be unable to ship in F15 because the systemd guys failed to do their homework, and there are likely to be several more before F15 dies. The idea I have at the moment is to ignore the advice to check package version, and instead have the triggerun script check to see whether the mysql sysv initscript file is present. I wonder whether anyone else has dealt with this and has working scriptlets? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
