Re: Improve the way rpm decides what is newer
On Tue, Nov 24, 2009 at 22:41:52 +0100, Michael Schwendt wrote: > On Tue, 24 Nov 2009 14:59:20 -0500, Przemek wrote: > > Especially during freeze of the development dist that's to be released > as N+1. That's the time when packagers make N and N-1 move ahead of N+1 > because freeze procedures. If N+1 doesn't get the same package updates > *and* upgrades as the older dists [because of "issues"], it simply isn't > ready to be released. Maybe we want to block packages that do that for a short time around the release (maybe from freeze to release + 1 week). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Tue, 24 Nov 2009 14:59:20 -0500, Przemek wrote: > Essentially, these proposals can be seen as attempts to introduce a > 2-dimensional ordering: on one hand, classifying packages by their > version number, and on the other hand by a distribution. Mathematically > this is impossible---it's a well-known mathematical fact that there's no > consistent ordering relation in a complex plane. Indeed, people came up > with use cases for both version number being more important and less > important than the distribution number. If you see it like that, ordering in the 1st dimension is a problem already, because it's not always possible to map upstream versions into RPM versions without violating a strict ordering relation. Fedora's versioning guidelines avoid many pitfalls, but odd cases remain -- and situations when you want to downgrade without creating a fake package version. > I agree that this is a 'process' issue---packages should be ordered > simply by the underlying software version and release, and there should > be a distribution release QA step that simply makes sure that all > released packages from distro N+1 are newer than latest updates in distro N Especially during freeze of the development dist that's to be released as N+1. That's the time when packagers make N and N-1 move ahead of N+1 because freeze procedures. If N+1 doesn't get the same package updates *and* upgrades as the older dists [because of "issues"], it simply isn't ready to be released. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On 11/21/2009 11:50 AM, Michael Schwendt wrote:
Given that Epoch can make an update go from a higher %{version} to a lower
one (which even may be a completely normal scenario for upstream project
splits), you can't avoid making Epoch the most-significant portion of RPM
version comparison. One can only work around versioning scheme flaws until
one runs into an unexpected problem where an Epoch is needed. Introduce
an Epoch, and it must be considered in any other explicit references
(Obsoletes'n'friends).
Essentially, these proposals can be seen as attempts to introduce a
2-dimensional ordering: on one hand, classifying packages by their
version number, and on the other hand by a distribution. Mathematically
this is impossible---it's a well-known mathematical fact that there's no
consistent ordering relation in a complex plane. Indeed, people came up
with use cases for both version number being more important and less
important than the distribution number.
I agree that this is a 'process' issue---packages should be ordered
simply by the underlying software version and release, and there should
be a distribution release QA step that simply makes sure that all
released packages from distro N+1 are newer than latest updates in distro N
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sun, 22 Nov 2009 21:26:11 -0500, Orcan wrote:
> On Sat, Nov 21, 2009 at 12:03 PM, Michael Schwendt wrote:
> > On Sat, 21 Nov 2009 11:31:27 -0500, Tony wrote:
> >
> >> On 09-11-21 06:40:45, drago01 wrote:
> >> ...
> >> > You misunderstood me, I was not suggesting adding another epoch but
> >> > simply bump the %{epoch} for every release.
> >>
> >> If this were really important to do, just putting the release first in
> >> the version would take care of it without dragging in Epochs.
> >
> > That's %build number (= super-Epoch) style:
> >
> > 1-2.10 < 2-2.10 < 3-2.10 < 4-2.20 < 5-2.3 (!) < 6-2.31 < 7-2.40
> > ... [a year later] ... 1337-3.0 < 1338-3.0 < 1339-3.10
> >
>
> This has the same effect as bumping the release tag on every update
> and not resetting it to 1 on upstream releases, and make the Release
> tag take precedence over the Version tag. Wasn't this proposed before?
Yeah, long ago. It doesn't fix much and even bears a higher risk of
breaking versioned Req/Obs/Conf/BR in ways that have been covered before
in this thread.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 08:16 -0800, Adam Williamson wrote: > it has the problem that we'd have to do something horrible one time to > switch to that system, of course, but that seems the 'cleanest' way to > do it. I'm still not sure it's necessary. I think as Jesse does - any > time this is broken indicates maintainer error, our work should focus on > helping maintainers not make errors. > Right, even if you do this horrible hack one day, the very next day we could have somebody submitting an update for f12 that is a major version newer than what gets put out on f13 and now you've got an "upgrade" in the form of a downgrade. Hope you didn't want to keep that data! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 12:03 PM, Michael Schwendt wrote:
> On Sat, 21 Nov 2009 11:31:27 -0500, Tony wrote:
>
>> On 09-11-21 06:40:45, drago01 wrote:
>> ...
>> > You misunderstood me, I was not suggesting adding another epoch but
>> > simply bump the %{epoch} for every release.
>>
>> If this were really important to do, just putting the release first in
>> the version would take care of it without dragging in Epochs.
>
> That's %build number (= super-Epoch) style:
>
> 1-2.10 < 2-2.10 < 3-2.10 < 4-2.20 < 5-2.3 (!) < 6-2.31 < 7-2.40
> ... [a year later] ... 1337-3.0 < 1338-3.0 < 1339-3.10
>
This has the same effect as bumping the release tag on every update
and not resetting it to 1 on upstream releases, and make the Release
tag take precedence over the Version tag. Wasn't this proposed before?
Orcan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
Mike McGrath wrote: > Epochs are nasty. Can anyone think of any other mechanism they could use > with rpm? Ubuntu's "really" hack? E.g. this version was used for Jaunty's K3b: "1.0.5+kde4svn935857+really1.0.5-3ubuntu5" Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
Am 2009-11-21 11:00, schrieb drago01: On Sat, Nov 21, 2009 at 10:49 AM, Conrad Meyer wrote: On Saturday 21 November 2009 01:38:35 am drago01 wrote: We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. The problem with this system, which has been pointed out before, is that upgrades using the Fedora N release DVD on an up-to-date Fedora N-1 system will replace newer versions of packages with older ones -- this is bad. "Bad" .. a yum update after the upgrade will fix it. What if the new version is incompatible? New versions are normally upwards compatible but not backware compatible. Say you install a new mysql, then upgrade the tables, newer mysql will read those tables, but not older mysql. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 18:50 +0100, Michael Schwendt wrote: > You said "without changing anything in rpm". How that? > > If you move anything like "fc12" (using a '-' bears a risk) into > %version makes it necessary to consider the change value in all > versioned dependencies, too. as I said, it has problems. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 09:30:33 -0800, Adam wrote: > On Sat, 2009-11-21 at 18:07 +0100, Michael Schwendt wrote: > > On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote: > > > > > I was going to suggest what seems an obvious alternative way to do what > > > Christian wants, without changing anything in rpm. Instead of: > > > > > > foobar-1.0-1.fc12.x86-64 > > > > > > have: > > > > > > foobar-fc12-1.0-1.x86-64 > > > > Insufficient. > > > > Making %dist most-significant is only sufficient for ordinary %dist > > upgrades, but doesn't replace everything %epoch is needed for: fixing > > issues with upstream versioning schemes, reverting accidental upgrades, > > resetting %version as a result of software project splits. > > I didn't mean it as a replacement for epoch, I meant it as a way of > handling the initial problem. Of course, it has problems in that regard > too, which is why I don't actually support doing anything like this. You said "without changing anything in rpm". How that? If you move anything like "fc12" (using a '-' bears a risk) into %version makes it necessary to consider the change value in all versioned dependencies, too. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 18:07 +0100, Michael Schwendt wrote: > On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote: > > > I was going to suggest what seems an obvious alternative way to do what > > Christian wants, without changing anything in rpm. Instead of: > > > > foobar-1.0-1.fc12.x86-64 > > > > have: > > > > foobar-fc12-1.0-1.x86-64 > > Insufficient. > > Making %dist most-significant is only sufficient for ordinary %dist > upgrades, but doesn't replace everything %epoch is needed for: fixing > issues with upstream versioning schemes, reverting accidental upgrades, > resetting %version as a result of software project splits. I didn't mean it as a replacement for epoch, I meant it as a way of handling the initial problem. Of course, it has problems in that regard too, which is why I don't actually support doing anything like this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 18:03 +0100, Michael Schwendt wrote: > Remember that you need to consider %epoch in any explicitly version > Requires/BuildRequires/Obsoletes/Conflicts, too. > > Requires: foo > 2.10 > > would become what to get accurate? And considering upstream's versioning > scheme flaw where 2.3 followed 2.20. Once you add a kind of Epoch to > that dependency, you don't want it to update often, as every bump of > an Epoch-like value can invalidate a versioned dependency. Nasty. good point. in other words, as we've been saying all along, this kind of change is just going to cause lots of pain for a gain that could more properly be made otherwise, so let's not do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote: > I was going to suggest what seems an obvious alternative way to do what > Christian wants, without changing anything in rpm. Instead of: > > foobar-1.0-1.fc12.x86-64 > > have: > > foobar-fc12-1.0-1.x86-64 Insufficient. Making %dist most-significant is only sufficient for ordinary %dist upgrades, but doesn't replace everything %epoch is needed for: fixing issues with upstream versioning schemes, reverting accidental upgrades, resetting %version as a result of software project splits. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 11:31:27 -0500, Tony wrote:
> On 09-11-21 06:40:45, drago01 wrote:
> ...
> > You misunderstood me, I was not suggesting adding another epoch but
> > simply bump the %{epoch} for every release.
>
> If this were really important to do, just putting the release first in
> the version would take care of it without dragging in Epochs.
That's %build number (= super-Epoch) style:
1-2.10 < 2-2.10 < 3-2.10 < 4-2.20 < 5-2.3 (!) < 6-2.31 < 7-2.40
... [a year later] ... 1337-3.0 < 1338-3.0 < 1339-3.10
[Alternatively with %dist being higher than %version or higher than %build.]
What would you make the file names look like?
> Epoch is the big hammer, and is troublesome to use in practice.
Remember that you need to consider %epoch in any explicitly version
Requires/BuildRequires/Obsoletes/Conflicts, too.
Requires: foo > 2.10
would become what to get accurate? And considering upstream's versioning
scheme flaw where 2.3 followed 2.20. Once you add a kind of Epoch to
that dependency, you don't want it to update often, as every bump of
an Epoch-like value can invalidate a versioned dependency. Nasty.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 09:43 -0600, Mike McGrath wrote: > > > We should just use release epochs, people might hate them for whatever > > > reasons, but they would easily prevent such issues from happing. > > > > > > > Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12. > > Really > > don't want to see that "upgrade" happen. > > > > Epochs are nasty. Can anyone think of any other mechanism they could use > with rpm? I'm not talking about what rpm can do today, but any other > mechanism we could make rpm do tomorrow that could replace epoch? I was going to suggest what seems an obvious alternative way to do what Christian wants, without changing anything in rpm. Instead of: foobar-1.0-1.fc12.x86-64 have: foobar-fc12-1.0-1.x86-64 it has the problem that we'd have to do something horrible one time to switch to that system, of course, but that seems the 'cleanest' way to do it. I'm still not sure it's necessary. I think as Jesse does - any time this is broken indicates maintainer error, our work should focus on helping maintainers not make errors. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 09:43:58 -0600 (CST), Mike wrote:
> Epochs are nasty. Can anyone think of any other mechanism they could use
> with rpm? I'm not talking about what rpm can do today, but any other
> mechanism we could make rpm do tomorrow that could replace epoch?
Given that Epoch can make an update go from a higher %{version} to a lower
one (which even may be a completely normal scenario for upstream project
splits), you can't avoid making Epoch the most-significant portion of RPM
version comparison. One can only work around versioning scheme flaws until
one runs into an unexpected problem where an Epoch is needed. Introduce
an Epoch, and it must be considered in any other explicit references
(Obsoletes'n'friends).
There's also the problem of Epoch visibility. It is not part of the
package file name (even if Yum and other tools don't hide the Epoch value
when printing package ids). Making it part of the file name, makes them
less clear/readible.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On 09-11-21 06:40:45, drago01 wrote:
...
> You misunderstood me, I was not suggesting adding another epoch but
> simply bump the %{epoch} for every release.
If this were really important to do, just putting the release first in
the version would take care of it without dragging in Epochs.
Epoch is the big hammer, and is troublesome to use in practice.
--
TonyN.:'
'
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009, Jesse Keating wrote: > > > On Nov 21, 2009, at 1:38, drago01 wrote: > > > On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson > > wrote: > > > On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote: > > > > Hi folks, > > > > > > > > I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and > > > > while going through the yum remove/add maneuver I pondered: > > > > - is there ever a time when, while upgrading from Fedora n to Fedora > > > > n+1 I would expect a package .fcn to be kept instead of getting > > > > the .fcn+1 instance ? > > > > My answer was: no > > > > > > > > So I wondered if there would be a simple way to make this happen > > > > regardless of whether a maintainer blunders and gets things slightly > > > > out of sync between the 2 or 3 current Fedora releases. > > > > > > To me, this is the wrong fix. The problem here isn't RPM's version > > > comparison logic, which is perfectly sound. Instead of nerfing up RPM > > > comparisons, which are already full of enough hidden mines, we should > > > just improve Fedora's package versioning conventions so this doesn't > > > happen, or at least happens less often. > > > > We should just use release epochs, people might hate them for whatever > > reasons, but they would easily prevent such issues from happing. > > > > Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12. Really > don't want to see that "upgrade" happen. > Epochs are nasty. Can anyone think of any other mechanism they could use with rpm? I'm not talking about what rpm can do today, but any other mechanism we could make rpm do tomorrow that could replace epoch? -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Nov 21, 2009, at 3:00, Michael Schwendt wrote:
On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
We should just use release epochs, people might hate them for
whatever
reasons, but they would easily prevent such issues from happing.
Vendor Epochs have been discussed years ago and have been rejected.
The normal %{epoch} in RPM Version Comparison is hidden and bad enough
already. We don't need another hidden "super-Epoch" that wins
version comparison even with that other %epoch.
There are times when you can push updates to current/old stable
releases
but not newer/latest releases. E.g. temporary breakage of build
requirements
or the buildsys target. All that's needed is an automated check,
such as
the old upgradepathcheck script. Plus to put this onto the release
criteria
list of items to check prior to a new final release of a dist as
well as
when pushing updates. Violated upgrade paths should trigger an alarm
bell.
That's planned as part of the build acceptance autoqa tests.
--
Jes
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Nov 21, 2009, at 1:38, drago01 wrote: On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson wrote: On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote: Hi folks, I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and while going through the yum remove/add maneuver I pondered: - is there ever a time when, while upgrading from Fedora n to Fedora n+1 I would expect a package .fcn to be kept instead of getting the .fcn+1 instance ? My answer was: no So I wondered if there would be a simple way to make this happen regardless of whether a maintainer blunders and gets things slightly out of sync between the 2 or 3 current Fedora releases. To me, this is the wrong fix. The problem here isn't RPM's version comparison logic, which is perfectly sound. Instead of nerfing up RPM comparisons, which are already full of enough hidden mines, we should just improve Fedora's package versioning conventions so this doesn't happen, or at least happens less often. We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12. Really don't want to see that "upgrade" happen. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 12:40:45 +0100, drago01 wrote:
> > On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
> >
> >> We should just use release epochs, people might hate them for whatever
> >> reasons, but they would easily prevent such issues from happing.
> >
> > Vendor Epochs have been discussed years ago and have been rejected.
> > The normal %{epoch} in RPM Version Comparison is hidden and bad enough
> > already. We don't need another hidden "super-Epoch" that wins
> > version comparison even with that other %epoch.
>
> You misunderstood me, I was not suggesting adding another epoch but
> simply bump the %{epoch} for every release.
Okay, but the effect would not be different. You could only bump
%epoch for every released build of a package and/or inbetween releases
of the dist. In case of the latter, there would be a conflict with
ordinary bumps of %epoch in situations where you can't avoid that.
For the former, it reminds me of "Serial: %(date +'%Y%m%d')" in
hylafax upstream src.rpm once more, which was kind of a super-Epoch.
And in either case, it would get really ugly as we already need to
be careful with Epoch bumps that must be reflected in any explicit
Requires/Obsoletes/Conflicts in other packages.
We are glad that most packages don't set %epoch or don't change it often
if it's set already. Or else we would have continued with the old
explicit "Epoch: 0" rule from fedora.us instead of removing it from
packages in Fedora Extras.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 12:00 PM, Michael Schwendt wrote:
> On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
>
>> We should just use release epochs, people might hate them for whatever
>> reasons, but they would easily prevent such issues from happing.
>
> Vendor Epochs have been discussed years ago and have been rejected.
> The normal %{epoch} in RPM Version Comparison is hidden and bad enough
> already. We don't need another hidden "super-Epoch" that wins
> version comparison even with that other %epoch.
You misunderstood me, I was not suggesting adding another epoch but
simply bump the %{epoch} for every release.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
> We should just use release epochs, people might hate them for whatever
> reasons, but they would easily prevent such issues from happing.
Vendor Epochs have been discussed years ago and have been rejected.
The normal %{epoch} in RPM Version Comparison is hidden and bad enough
already. We don't need another hidden "super-Epoch" that wins
version comparison even with that other %epoch.
There are times when you can push updates to current/old stable releases
but not newer/latest releases. E.g. temporary breakage of build requirements
or the buildsys target. All that's needed is an automated check, such as
the old upgradepathcheck script. Plus to put this onto the release criteria
list of items to check prior to a new final release of a dist as well as
when pushing updates. Violated upgrade paths should trigger an alarm bell.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Fri, 20 Nov 2009 18:17:57 -0800, Adam Williamson wrote: > To me, this is the wrong fix. The problem here isn't RPM's version > comparison logic, which is perfectly sound. Instead of nerfing up RPM > comparisons, which are already full of enough hidden mines, we should > just improve Fedora's package versioning conventions so this doesn't > happen, or at least happens less often. Let me try to give 3 examples why I think a Vendor comparison, with the ordering defined in a config file, can be useful: 1. Some group of people would like to use Fedora for most packages except kernel, where they want to build a low-latency/whatever-funky option version. They create repo with Vendor "Low Latency" and the folks who are interested to use it add the repo to their yum.conf.d and put in the config file: "Low Latency" > "Fedora Project" and I think they'll get what they want, even if they do not keep exactly in sync with the Fedora repo update. 2. Similarly, if a user wishes to rebuild some of the Fedora packages using different compiler options because they think the execution speed will be improved on their hardware, they can simply rebuild the SRPM with the tweaked options and define Vendor as "My Fedora", and put: "My Fedora" > "Fedora Project" and they can then happily continue to receive Fedora updates for the packages they did not tweak and not worry that their tweaked packages will be replaced. 3. Suppose repo from Vendor "Funky Repo" provides some not-available elsewhere packages, but it also offers a mix of rebuilt packages from Fedora which you would rather not use, in this case you could add the repo and put in config: "Funky Repo" < "Fedora Project" and so yum would only select there packages that are not found in Fedora. Cheers, Christian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 10:49 AM, Conrad Meyer wrote: > On Saturday 21 November 2009 01:38:35 am drago01 wrote: >> We should just use release epochs, people might hate them for whatever >> reasons, but they would easily prevent such issues from happing. > > The problem with this system, which has been pointed out before, is that > upgrades using the Fedora N release DVD on an up-to-date Fedora N-1 system > will replace newer versions of packages with older ones -- this is bad. "Bad" .. a yum update after the upgrade will fix it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Saturday 21 November 2009 01:38:35 am drago01 wrote: > We should just use release epochs, people might hate them for whatever > reasons, but they would easily prevent such issues from happing. The problem with this system, which has been pointed out before, is that upgrades using the Fedora N release DVD on an up-to-date Fedora N-1 system will replace newer versions of packages with older ones -- this is bad. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson wrote: > On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote: >> Hi folks, >> >> I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and >> while going through the yum remove/add maneuver I pondered: >> - is there ever a time when, while upgrading from Fedora n to Fedora >> n+1 I would expect a package .fcn to be kept instead of getting >> the .fcn+1 instance ? >> My answer was: no >> >> So I wondered if there would be a simple way to make this happen >> regardless of whether a maintainer blunders and gets things slightly >> out of sync between the 2 or 3 current Fedora releases. > > To me, this is the wrong fix. The problem here isn't RPM's version > comparison logic, which is perfectly sound. Instead of nerfing up RPM > comparisons, which are already full of enough hidden mines, we should > just improve Fedora's package versioning conventions so this doesn't > happen, or at least happens less often. We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote: > Hi folks, > > I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and > while going through the yum remove/add maneuver I pondered: > - is there ever a time when, while upgrading from Fedora n to Fedora > n+1 I would expect a package .fcn to be kept instead of getting > the .fcn+1 instance ? > My answer was: no > > So I wondered if there would be a simple way to make this happen > regardless of whether a maintainer blunders and gets things slightly > out of sync between the 2 or 3 current Fedora releases. To me, this is the wrong fix. The problem here isn't RPM's version comparison logic, which is perfectly sound. Instead of nerfing up RPM comparisons, which are already full of enough hidden mines, we should just improve Fedora's package versioning conventions so this doesn't happen, or at least happens less often. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
W dniu 21.11.2009 02:02, Christian Iseli pisze: > On Sat, 21 Nov 2009 01:36:28 +0100, Kevin Kofler wrote: >> Including Vendor in comparisons is just FAIL. Packages often move >> from Fedora to RPM Fusion as legal problems are found or from RPM >> Fusion to Fedora as legal problems are cleared, there's no one vendor >> which can have precedence. > > I don't follow your reasoning there. In the config file you define: > "Fedora Project" == "RPM Fusion" > and the comparison, being equal, then proceeds to VendorRelease, which > would be identical and then you end up in the same situation we are in > now: the version-release in RPM Fusion needs to be higher than the one > you removed from the Fedora repo. > -1 What you have now is a few (never had more than 10) packages from an earlier branch of the distro. Most of the times they work fine, so this is basically a non-issue. Hacking around with release super-epoch and vendors is only going to cause pain. Application upgrades are usually coded to cope with the older config files format and migrate them to older ones, this obviously won't work the other way round. Seriously guys, is there nothing better to do than hunting around f(x-1) packages? Julian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 21 Nov 2009 01:36:28 +0100, Kevin Kofler wrote: > Including Vendor in comparisons is just FAIL. Packages often move > from Fedora to RPM Fusion as legal problems are found or from RPM > Fusion to Fedora as legal problems are cleared, there's no one vendor > which can have precedence. I don't follow your reasoning there. In the config file you define: "Fedora Project" == "RPM Fusion" and the comparison, being equal, then proceeds to VendorRelease, which would be identical and then you end up in the same situation we are in now: the version-release in RPM Fusion needs to be higher than the one you removed from the Fedora repo. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
Christian Iseli wrote: > A.Vendor <=> B.Vendor Including Vendor in comparisons is just FAIL. Packages often move from Fedora to RPM Fusion as legal problems are found or from RPM Fusion to Fedora as legal problems are cleared, there's no one vendor which can have precedence. On the other hand, having the distro version as some sort of Super-Epoch has been discussed at times and I think it might be a good idea. It does have drawbacks though, because it means that upgrading from the DVD will downgrade some stuff and some applications don't like being downgraded at all. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Improve the way rpm decides what is newer
Hi folks, I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and while going through the yum remove/add maneuver I pondered: - is there ever a time when, while upgrading from Fedora n to Fedora n+1 I would expect a package .fcn to be kept instead of getting the .fcn+1 instance ? My answer was: no So I wondered if there would be a simple way to make this happen regardless of whether a maintainer blunders and gets things slightly out of sync between the 2 or 3 current Fedora releases. I did not find a real easy way, but one way which does not seem too hard to implement would be to introduce one additional tag in a package named something like VendorRelease. Then, given package A and B we could implement the "what is newer" comparison as follows: A.Vendor <=> B.Vendor || A.VendorRelease <=> B.VendorRelease || A.Epoch <=> B.Epoch || A.Version <=> B.Version || A.Release <=> B.Release The VendorRelease, Epoch, Version and Release would be implemented using the usual, current comparison method. The Vendor comparison would be taken from a config file, where the admin can decide what is the preferred Vendor tag. We might thus be able to solve the old dispute of having repotags by punting it into the hands of the user. If the user is happy to take newer versioned packages from some third party repo, he can just define both Vendors as equal in the config file. This would also allow getting rid of Epochs from one Fedora release to the next, since a newer VendorRelease would trump the non-null Epoch. I'm a bit afraid this might degenerate into another flame fest, but having slept on it I still think this idea has some merit. So putting on my asbestos underpants and waiting to see what will come out of this... Cheers, Christian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
