[Rpm-maint] RPM 4.13.0-alpha released
lkardos at redhat.com
Tue Aug 4 13:43:01 UTC 2015
The problem is when you upgrade distro N to N+2 both triggers should
be run but only one was run, which was confusing so we disallowed
triggers fired by the same package with overlapping version intervals.
And initscripts <= 4.72 and initscripts <= 8.38-2 overlaps.
Have a look at bugs #585384, #702378 that initiate this change.
----- Original Message -----
> From: "Thierry Vignaud" <thierry.vignaud at gmail.com>
> To: "Florian Festi" <ffesti at redhat.com>
> Cc: rpm-maint at lists.rpm.org
> Sent: Thursday, July 30, 2015 12:18:41 PM
> Subject: Re: [Rpm-maint] RPM 4.13.0-alpha released
> On 24 July 2015 at 13:48, Florian Festi <ffesti at redhat.com> wrote:
> > Time to wrap things up and stabilize all that changes to a new release.
> > There are two big new features that we hope to get feedback on:
> > * Boolean (aka "Rich") Dependencies
> > * File triggers
> > Beside that there are many other fixes, improvements and cleanups.
> > For download information and further details, see the draft release
> > notes: http://rpm.org/wiki/Releases/4.13.0
> > On behalf of the rpm-team,
> rpm-4.13 is stricter about multiple (classic package) triggers:
> "error: line 320: Trigger fired by the same package is already defined
> in spec file: %triggerpostun -- initscripts < 8.88-5"
> This is caused by this which worked fine until now:
> %triggerpostun -- initscripts <= 4.72
> %triggerpostun -- initscripts <= 8.38-2
> Here I can safely kill very old triggers.
> But there's obviously real cases where we might want to have two
> similar triggers, only differing by the version that trigger it.
> (eg: fixing a 1st issue when upgrading to distro N to N+2, and fixing
> another one when upgrading from distro N+1 to N+2)
> This is due to this commit:
> This is breaking existing packages
> Why imposing this limit?
> Why would it be OK for file triggers but not for package triggers?
> Do we really want to enforce at rpm level the fact that some distro
> only support upgrading from version N to version N+1?
> I suggest we revert that commit (& adjust
> See you
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
More information about the Rpm-maint