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 Development

 
 
LinkBack Thread Tools
 
Old 07-25-2011, 07:57 PM
Bill Nottingham
 
Default Systemd transition prevents updating older release branches??

Tom Lane (tgl@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
 
Old 07-25-2011, 07:57 PM
Bill Nottingham
 
Default Systemd transition prevents updating older release branches??

Tom Lane (tgl@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
 
Old 07-25-2011, 08:15 PM
Tom Lane
 
Default Systemd transition prevents updating older release branches??

Bill Nottingham <notting@redhat.com> writes:
> Tom Lane (tgl@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
 
Old 07-25-2011, 08:15 PM
Tom Lane
 
Default Systemd transition prevents updating older release branches??

Bill Nottingham <notting@redhat.com> writes:
> Tom Lane (tgl@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
 
Old 07-25-2011, 09:48 PM
Toshio Kuratomi
 
Default 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-25-2011, 09:48 PM
Toshio Kuratomi
 
Default 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-26-2011, 10:17 AM
Michal Hlavinka
 
Default 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
 
Old 07-26-2011, 02:37 PM
Tom Lane
 
Default Systemd transition prevents updating older release branches??

Matthias Saou <thias@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
 
Old 07-26-2011, 02:58 PM
Toshio Kuratomi
 
Default Systemd transition prevents updating older release branches??

On Tue, Jul 26, 2011 at 10:37:43AM -0400, Tom Lane wrote:
> Matthias Saou <thias@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-26-2011, 03:20 PM
Tom Lane
 
Default Systemd transition prevents updating older release branches??

Toshio Kuratomi <a.badger@gmail.com> writes:
> On Tue, Jul 26, 2011 at 10:37:43AM -0400, Tom Lane wrote:
>> 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.

That argument seems like a straw man, considering that the file to be
tested for was provided by the previous version of mysql-server, and
that the test would only be made when we know we are upgrading (not
freshly installing) mysql-server. It's hardly likely that anyone was
providing a conflicting version of it. Moreover, what's the downside
if someone did? His sysv-based boot configuration would get migrated
to systemd. Not exactly fatal, I think.

> Please read the link I posted to Ville's message instead[1]_.

Thanks, but I do not intend to make it my job to do extensive testing
of someone else's scriptlets. This work should have been done by the
systemd team before foisting a poorly-thought-out upgrade process on
the rest of us.

On balance I still think that Michal's solution is the least risky.
None of these solutions are perfect, but that one is the least likely
to fail over time.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:49 AM.

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