Re: Systemd transition prevents updating older release branches??
On 07/25/2011 09:07 PM, Tom Lane wrote:
In
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
I read that conversion of a package using a SysV initscript to systemd
units requires a trigger with a NEVR condition, and that
# Note: the NEVR in trigger scripts should all be the version in
# which the package switched to systemd unit files and the comparision
# should be less than. Using= the last version with the sysV script won't
# work for several reasons:
# 1) disttag is different between Fedora releases
# 2) An update in an old Fedora release may create a newer NEVR
#Note that this means an update in an older Fedora release must be NEVR
#lower than this. Freezing the version and release of the old package and
#using a number after the disttag is one way to do this. Example:
#httpd-1.0-1%{?dist} = httpd-1.0-1%{?dist}.1
IOW, once I push a mysql update with native systemd support into
rawhide, I'll be forbidden from ever rebasing mysql in F15 up to
a newer upstream patch release. Considering that upstream issues
bug-fix releases about once a month, this is hardly acceptable.
I'll have the same problem with postgresql, too.
What's seeming like a better option is to bump the package's Epoch
for the systemd-native release.
I don't like epoch changes too much. So, I've used different approach.
In %post section I have script that checks for old init script presence.
Something like:
if [ -f %{_initddir}/script ]; then
do migration here
ff
Apparently, this won't work if you add package-sysv package with old
init script too.
Just my two cents
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
Toshio Kuratomi wrote : Regarding the fragility argument in reply to notting's clarification; do note that the fragility there only lasts until that Fedora release goes EOL and therefore can no longer receive updates) less than a year now for Fedora 15. The fragility of packagers remembering that the package has an epoch seems lower on a case-by-case basis but its effect lasts for as long as we ship that package. The fragility you mention will resurface when RHEL7 is released then stay around for many many years for anyone maintaining EPEL6 and EPEL7 packages. Definitely something worth keeping in mind. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 14 (Laughlin) - Linux kernel 2.6.35.13-91.fc14.x86_64 Load : 0.23 0.29 0.40 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
Matthias Saou th...@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net writes: Toshio Kuratomi wrote : Regarding the fragility argument in reply to notting's clarification; do note that the fragility there only lasts until that Fedora release goes EOL and therefore can no longer receive updates) less than a year now for Fedora 15. The fragility of packagers remembering that the package has an epoch seems lower on a case-by-case basis but its effect lasts for as long as we ship that package. The fragility you mention will resurface when RHEL7 is released then stay around for many many years for anyone maintaining EPEL6 and EPEL7 packages. Definitely something worth keeping in mind. Yes, it's actually the eventual RHEL transition that scares me more than F15. Given all the problems created by the (premature IMO) systemd transition, anybody running database servers on F15 is already accustomed to pain. Michal Hlavinka's solution of explicitly testing for the old sysv init script seems like a win from here, since I don't intend to continue packaging that. Anyone have an objection to that approach? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
On Tue, Jul 26, 2011 at 10:37:43AM -0400, Tom Lane wrote: Matthias Saou th...@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net writes: Toshio Kuratomi wrote : Regarding the fragility argument in reply to notting's clarification; do note that the fragility there only lasts until that Fedora release goes EOL and therefore can no longer receive updates) less than a year now for Fedora 15. The fragility of packagers remembering that the package has an epoch seems lower on a case-by-case basis but its effect lasts for as long as we ship that package. The fragility you mention will resurface when RHEL7 is released then stay around for many many years for anyone maintaining EPEL6 and EPEL7 packages. Definitely something worth keeping in mind. Yes, it's actually the eventual RHEL transition that scares me more than F15. Given all the problems created by the (premature IMO) systemd transition, anybody running database servers on F15 is already accustomed to pain. I've been told many times that there's no upgrade path from Fedora = RHEL, from RHEL to Fedora, or from RHELX to RHEL(X+1). With that in mind there's no problem here. RHEL7, I'd deeply hope, will ship with all its services ported to a single init system standard and then those services will never migrate. Michal Hlavinka's solution of explicitly testing for the old sysv init script seems like a win from here, since I don't intend to continue packaging that. Anyone have an objection to that approach? Yes, I object. As Michal said in his post, the %post that he uses is problematic if someone has installed a package with sysv init scripts for that service. Please read the link I posted to Ville's message instead[1]_. Ville wrote his proposed scriptlets with awareness of that problem and, in his testing, they are able to deal with the problem provided that your old package used service instead of calling the init script directly (service mysql condrestart rather than /etc/init.d/mysql condrestart). He also proposes some scriptlets to address the init script case. No ones tested them on the FPC but Ville himself has done testing of them. If you'd like to test the permutations of what the scriptlets do in different permutations of installing and upgrading and documenting that we'd be happy to take a look at changing the scriptlets in the Packaging Guideline to what he proposes. .. _[1]: http://lists.fedoraproject.org/pipermail/packaging/2011-July/007846.html -Toshio pgpAD86M84UH6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
Tom Lane (t...@redhat.com) said: Bill Nottingham nott...@redhat.com writes: Tom Lane (t...@redhat.com) said: IOW, once I push a mysql update with native systemd support into rawhide, I'll be forbidden from ever rebasing mysql in F15 up to a newer upstream patch release. Considering that upstream issues bug-fix releases about once a month, this is hardly acceptable. No, it just means you'll have to tweak the versioning in the rawhide trigger at the same time. That sounds too fragile for words. Even assuming that I remember to do it each time, what will happen to people who are already running the previous rawhide version? Seems like yum update will result in running the trigger again. If the trigger's written correctly, that shouldn't make a difference. An example: %triggerun -- ntpdate 4.2.6p3-3 if /sbin/chkconfig --level 3 ntpdate ; then /bin/systemctl enable ntpdate.service /dev/null || : fi exit 0 If you don't continue to ship the ntpdate init script in the package once you've migrated to systemd, this trigger is harmless if triggered again. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
On 07/26/2011 12:48 AM, Toshio Kuratomi wrote: Ville recently proposed a different set of scriptlets that would do away with triggers but no one's committed to testing that the triggers work in all cases (lots of package upgrades and lots of reboots are needed to test that the scriptlets upgrade packages the way they're intended to). I will do some testing, but before starting it, I want a consensus on a finite set of test cases and their expected results so that the amount of work required is finite, see my messages on the packaging list today for an initial proposal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
Tom Lane (t...@redhat.com) said:
# Note: the NEVR in trigger scripts should all be the version in
# which the package switched to systemd unit files and the comparision
# should be less than. Using = the last version with the sysV script won't
# work for several reasons:
# 1) disttag is different between Fedora releases
# 2) An update in an old Fedora release may create a newer NEVR
#Note that this means an update in an older Fedora release must be NEVR
#lower than this. Freezing the version and release of the old package and
#using a number after the disttag is one way to do this. Example:
#httpd-1.0-1%{?dist} = httpd-1.0-1%{?dist}.1
IOW, once I push a mysql update with native systemd support into
rawhide, I'll be forbidden from ever rebasing mysql in F15 up to
a newer upstream patch release. Considering that upstream issues
bug-fix releases about once a month, this is hardly acceptable.
No, it just means you'll have to tweak the versioning in the rawhide
trigger at the same time.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
Bill Nottingham nott...@redhat.com writes: Tom Lane (t...@redhat.com) said: IOW, once I push a mysql update with native systemd support into rawhide, I'll be forbidden from ever rebasing mysql in F15 up to a newer upstream patch release. Considering that upstream issues bug-fix releases about once a month, this is hardly acceptable. No, it just means you'll have to tweak the versioning in the rawhide trigger at the same time. That sounds too fragile for words. Even assuming that I remember to do it each time, what will happen to people who are already running the previous rawhide version? Seems like yum update will result in running the trigger again. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
On Mon, Jul 25, 2011 at 03:07:25PM -0400, Tom Lane wrote: What's seeming like a better option is to bump the package's Epoch for the systemd-native release. Discuss. Epoch would work for this. We didn't put Epoch into the guidelines because there's a general consensus that epoch is easy for packagers to get wrong (in terms of remembering to add the epoch ot their dependencies) and its unfortunately, not very visible to people consuming packages (it's not in the default rpm filename, for instance). The guidelines do not prohibit the use of epoch here... but if you do use it, it'll saddle package maintainers with the need to remember it in their dependencies forever. Ville recently proposed a different set of scriptlets that would do away with triggers but no one's committed to testing that the triggers work in all cases (lots of package upgrades and lots of reboots are needed to test that the scriptlets upgrade packages the way they're intended to). http://lists.fedoraproject.org/pipermail/packaging/2011-July/007846.html Regarding the fragility argument in reply to notting's clarification; do note that the fragility there only lasts until that Fedora release goes EOL and therefore can no longer receive updates) less than a year now for Fedora 15. The fragility of packagers remembering that the package has an epoch seems lower on a case-by-case basis but its effect lasts for as long as we ship that package. -Toshio pgpE03nJ3SeZy.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
