Why do we need FC version attached to the package name?
Hi all, Why is necessary to have a particular package tagged as fc10 or fc11?? What is the significance.? As it is, versions of the packages keep changing independent of the Fedora versions. For example : kdebase-4.2.3-1.fc10.i386 is available for fc10 and the same version kdebase-4.2.3-1.fc11.i386 is available for fc11 It wastes space,time(while upgrading from fc10 to fc11) (I invite ppl to add to the list) Regards Bharath -- All roads lead to some other roads -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, Jun 21, 2009 at 2:42 PM, Bharath wrote: > Hi all, > > Why is necessary to have a particular package tagged as fc10 or fc11?? What > is the significance.? As it is, versions of the packages keep changing > independent of the Fedora versions. > For example : > > kdebase-4.2.3-1.fc10.i386 is available for fc10 > and the same version > kdebase-4.2.3-1.fc11.i386 is available for fc11 > > It wastes space,time(while upgrading from fc10 to fc11) (I invite ppl to > add to the list) The package has been rebuilt with a newer gcc and a newer rpm (stringer hash) so no its not the same package with a different name. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
I second this. Can't we have only one stable repository which is for "Fedora", instead of one each FC10, FC11, ...? "development", "testing" and "stable" three repositories for "Fedora" as a whole and snapshots of stable as releases? That would make definitely user's life simple and I believe would make so even for the developers. Regards, Prasad 2009/6/21 Bharath : > Hi all, > > Why is necessary to have a particular package tagged as fc10 or fc11?? What > is the significance.? As it is, versions of the packages keep changing > independent of the Fedora versions. > For example : > > kdebase-4.2.3-1.fc10.i386 is available for fc10 > and the same version > kdebase-4.2.3-1.fc11.i386 is available for fc11 > > It wastes space,time(while upgrading from fc10 to fc11) (I invite ppl to > add to the list) > > Regards > Bharath > > -- > All roads lead to some other roads > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Prasad H. L. PhD Student (with Dr. Shalabh Bhatnagar) Department of Computer Science and Automation, Indian Institute of Science, Bangalore - 560012 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, 2009-06-21 at 18:22 +0530, Prasad H. L. wrote:
> I second this.
>
> Can't we have only one stable repository which is for "Fedora",
> instead of one each FC10, FC11, ...?
>
> "development", "testing" and "stable" three repositories for "Fedora"
> as a whole and snapshots of stable as releases?
>
> That would make definitely user's life simple and I believe would make
> so even for the developers.
But that's the way it is now. Rawhide (development) is the bleeding-edge
distribution, which is frozen every six months for a stable release.
There is a sound need for these releases: you have to stabilize the
package set so that you don't have to use a broken system. If you want
to try what happens when any system components can change whenever they
want, breaking dependencies on other packages, use rawhide.
The versioning of packages with %{?dist} (.fc10, .fc11 and so on) also
has a purpose. Different versions of Fedora use different compiler
versions and optimization flags that are not present in older versions.
That's why it's important that when you update to a newer distribution
all of your packages are updated as well to versions compiled with the
new compiler and optimization flags.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, 21 Jun 2009 14:52:18 +0200, drago01 wrote: > On Sun, Jun 21, 2009 at 2:42 PM, Bharath wrote: > > Hi all, > > > > Why is necessary to have a particular package tagged as fc10 or fc11?? What > > is the significance.? As it is, versions of the packages keep changing > > independent of the Fedora versions. > > For example : > > > > kdebase-4.2.3-1.fc10.i386 is available for fc10 > > and the same version > > kdebase-4.2.3-1.fc11.i386 is available for fc11 > > > > It wastes space,time(while upgrading from fc10 to fc11) (I invite ppl to > > add to the list) > > The package has been rebuilt with a newer gcc and a newer rpm > (stringer hash) so no its not the same package with a different name. Yes, and let me add that the ".fc10" and ".fc11" (the dist-tag) is part of the package "Release" value not just the package file name. That makes the .fc11 package "newer than" the .fc10 package in RPM's view, which is particularly important if internally it really differs from the .fc10 build (e.g. in terms of compiler generated code, library versions, dependencies). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, 2009-06-21 at 17:14 +0200, Michael Schwendt wrote: > > The package has been rebuilt with a newer gcc and a newer rpm > > (stringer hash) so no its not the same package with a different name. > > Yes, and let me add that the ".fc10" and ".fc11" (the dist-tag) is part > of the package "Release" value not just the package file name. > That makes the .fc11 package "newer than" the .fc10 package > in RPM's view, which is particularly important if internally > it really differs from the .fc10 build (e.g. in terms of compiler > generated code, library versions, dependencies). Exactly: say that in Fedora 10 package foo-1.0-1 is built against libbar.so.4, but in Fedora 11 it's built against libbar.so.5 then you might end up in trouble with a distribution upgrade if libbar.so.4 doesn't exist in the new distribution. [I don't know whether yum is capable of handling this.] When you add the distro version into the release tag, you have foo-1.0-1.fc10 in Fedora 10 and foo-1.0-1.fc11 in Fedora 11, then the Fedora 11 version will automatically replace the Fedora 10 version. PS. I am not aware of any distribution without some kind of a frozen release system - even the source based distros such as Gentoo have stabilized sets of the base components. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/21/2009 09:14 AM, Michael Schwendt wrote: Yes, and let me add that the ".fc10" and ".fc11" (the dist-tag) is part of the package "Release" value not just the package file name. That makes the .fc11 package "newer than" the .fc10 package in RPM's view, which is particularly important if internally I *wish* it made a difference. I did an upgrade am an left with a host of fc10 packages because the fc11 ones weren't considered newer. For example people with updates-testing enabled on fc10 got a non-upgraded yum because the versions were the same (except for fc10/fc11) and it stopped working because python went from 2.5 to 2.6 So to RPM the fc10/fc11 isn't being compared, at least not that I can see... it really differs from the .fc10 build (e.g. in terms of compiler generated code, library versions, dependencies). It would definitely help if it did though... -- Nathanael d. Noblet T: 403.875.4613 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: > I *wish* it made a difference. I did an upgrade am an left with a host > of fc10 packages because the fc11 ones weren't considered newer. > > For example people with updates-testing enabled on fc10 got a > non-upgraded yum because the versions were the same (except for > fc10/fc11) and it stopped working because python went from 2.5 to 2.6. That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathanael D. Noblet wrote: > On 06/21/2009 09:14 AM, Michael Schwendt wrote: > >> Yes, and let me add that the ".fc10" and ".fc11" (the dist- tag) is part >> of the package "Release" value not just the package file name. >> That makes the .fc11 package "newer than" the .fc10 package >> in RPM's view, which is particularly important if internally > > > I *wish* it made a difference. I did an upgrade am an left with a host > of fc10 packages because the fc11 ones weren't considered newer. > > > For example people with updates-testing enabled on fc10 got a > non-upgraded yum because the versions were the same (except for > fc10/fc11) and it stopped working because python went from 2.5 to > 2.6 So to RPM the fc10/fc11 isn't being compared, at least not that > I can see... > >> it really differs from the .fc10 build (e.g. in terms of compiler >> generated code, library versions, dependencies). > > It would definitely help if it did though... > This is a broken upgrade path. It's a bug with the package. However, if you're upgrading to the DVD, yes, there will be broken deps from updates-testing. Since updates-testing of F(n-1) is a moving target that can pass GA of Fn's NVR set very quickly, forcing F11 > F10 in all cases is unacceptable and would stunt releases that aren't (Rawhide - 1). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko+wLsACgkQiPi+MRHG3qQp0wCfSRH0iwR13qyiV7M0m2D1mQ4g cygAnRFzK2EbUzHIGAMO+aSRNVoVDmoY =c0Ff -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 1:08, Dave Jones wrote: On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: I *wish* it made a difference. I did an upgrade am an left with a host of fc10 packages because the fc11 ones weren't considered newer. For example people with updates-testing enabled on fc10 got a non-upgraded yum because the versions were the same (except for fc10/fc11) and it stopped working because python went from 2.5 to 2.6. That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 12:54 PM, Jesse Keating wrote: > > Not possible while we allow people to keep making updates to the older > releases. Those updates quickly become version ( not just release even > ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 22/06/09 08:24, Jesse Keating wrote: That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. -- Jes Maybe, freeze all updates nearing a GA, FRank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:26, Rahul Sundaram wrote: On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. Rahul If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:29, Frank Murphy wrote: On 22/06/09 08:24, Jesse Keating wrote: That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. -- Jes Maybe, freeze all updates nearing a GA, And keep them frozen indefinitely? -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote: > On Jun 22, 2009, at 9:26, Rahul Sundaram > wrote: > > On 06/22/2009 12:54 PM, Jesse Keating wrote: > >> Not possible while we allow people to keep making updates to the > >> older > >> releases. Those updates quickly become version ( not just release > >> even > >> ) higher than the static copies on the release medium and repos. > > > > Is there any proposed solution to this problem? We can't just continue > > to break upgrade paths and call it the way things are done. > > > If you have any ideas I'd like to hear them. A super epoch has already > been suggested but that just masks the problem and may cause unwanted > downgrades. Any solution either involves severly limiting what kind of > updates can be done or requiring network access during upgrades. Does anaconda currently force installs of core packages such as yum? This is quite important if the version in the old distro is newer than that on the DVD. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 22/06/09 08:32, Jesse Keating wrote: Maybe, freeze all updates nearing a GA, And keep them frozen indefinitely? -- Jes Duh!, forgot the coffee. That would get the early adopters, then nearing EOL of current eg 9. Only allow updates for 11. Same when 10 is EOL. Just update most recent release Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:34, Jussi Lehtola wrote: On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote: On Jun 22, 2009, at 9:26, Rahul Sundaram wrote: On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. Does anaconda currently force installs of core packages such as yum? This is quite important if the version in the old distro is newer than that on the DVD. No because anaconda has no idea if forcing it would actually result in a working system. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:38, Frank Murphy wrote: On 22/06/09 08:32, Jesse Keating wrote: Maybe, freeze all updates nearing a GA, And keep them frozen indefinitely? -- Jes Duh!, forgot the coffee. That would get the early adopters, then nearing EOL of current eg 9. Only allow updates for 11. Same when 10 is EOL. Just update most recent release Doesn't actually help anything. People upgrading from the most recent release will run into issues unless we stop updates around devel freeze, which would leave more than a month without updates and would cut our 13 month life to 5 or so. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 01:01 PM, Jesse Keating wrote: > > If you have any ideas I'd like to hear them. A super epoch has already > been suggested but that just masks the problem and may cause unwanted > downgrades. Any solution either involves severly limiting what kind of > updates can be done or requiring network access during upgrades. I can't think of any fool proof solutions but there are a couple of things that might help: * Run checks on upgrade paths and inform the maintainers when are about to break an upgrade path (ie) before signing it. I noticed a few maintainers I talked to just weren't aware they were doing so and neither were they aware of the %dist.1 trick to workaround the problem atleast in some cases. They might choose to delay an update where it is feasible to do so. Not sure what we can do about security updates or critical bug fixes breaking the upgrade path for the next release. Ideally, the maintainer should have pushed it in sync for the two releases. * In preupgrade, if a user has updates-testing repo enabled, make sure it is enabled for the release they are upgrading to. I think I have a RFE filed on this. This is a bit of a corner case. Rahul Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, 21 Jun 2009 19:08:11 -0400, Dave wrote: > On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: > > > I *wish* it made a difference. I did an upgrade am an left with a host > > of fc10 packages because the fc11 ones weren't considered newer. > > > > For example people with updates-testing enabled on fc10 got a > > non-upgraded yum because the versions were the same (except for > > fc10/fc11) and it stopped working because python went from 2.5 to 2.6. > > That's messed up. We used to check just before release time that this > situation never occured. ^ No, that's not entirely true. The full story is from the book "What sucks about Fedora". There used to be regular runs of the upgradecheck.py script from the Fedora Extras era, which mailed the fedora-maintainers list (and later fedora-devel list), and later the upgradecheckspam.py script which mailed package owners directly. That helped with getting upgrade problems fixed, but it wasn't part of any release policy to make sure all upgrade path violations would have to get fixed. Then with the switch to koji+bodhi a few package owners complained loudly about false positives that were caused by pending builds, which were not found in the master repo yet. A few other package owners jumped upon the train and questioned the usefulness of the script, since they were of the opinion that breaking upgrade paths the way they did it with updates-testing and stable updates would not be considered a problem. Even later there used to be another script that queried koji for more accurate package release versions, but it has never been run regularly, not even prior to the next Fedora release. > It should probably be added to the rel-eng > release checklist if it isn't there already. Does rel-eng have any interest at all in avoiding some upgrade path problems? I don't see that. Running a script to catch _some_ issues would be tons better than not running a script at all. The problem is not limited to some people upgrading from F10 updates-testing to F11 without updates-testing. There are still packagers who bump %version or %release in old dist updates without considering the consequences with regard to dist upgrades. And in Rawhide? Just because a packager doesn't track Rawhide for some time should not imply that files in "devel" cvs become older than in the other dist branches or that updates for released dists get ahead of builds in Rawhide. The freeze only adds to the problem, because packagers can push upgrades for old dists while the unreleased dists remains frozen. It's also simply a crap decision if packagers quickly mark F10 updates as stable while the corresponding F11 update has not seen any testing at all (while it's stuck in the growing list of pending updates in bodhi or waiting for release of F11). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 01:14:55PM +0530, Rahul Sundaram wrote: >On 06/22/2009 01:01 PM, Jesse Keating wrote: > >> >> If you have any ideas I'd like to hear them. A super epoch has already >> been suggested but that just masks the problem and may cause unwanted >> downgrades. Any solution either involves severly limiting what kind of >> updates can be done or requiring network access during upgrades. > >I can't think of any fool proof solutions but there are a couple of >things that might help: > >* Run checks on upgrade paths and inform the maintainers when are about >to break an upgrade path (ie) before signing it. I noticed a few >maintainers I talked to just weren't aware they were doing so and >neither were they aware of the %dist.1 trick to workaround the problem >atleast in some cases. They might choose to delay an update where it is >feasible to do so. Not sure what we can do about security updates or >critical bug fixes breaking the upgrade path for the next release. >Ideally, the maintainer should have pushed it in sync for the two >releases. I think you mean "before pushing" rather than signing, but this idea has been suggested before. The good thing is, we could possibly tie this into bodhi during update submission. It's fairly easy to do NEVR comparisons and we don't need full repos for the upgrade path checks to happen since we can use the update information and koji tags. The bad thing is, this suffers from the same problems every other auto-QA suggestion has. Namely, no code, nobody with time to write the code, and it potentially slows things down even more. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 12:01:29PM +0200, Michael Schwendt wrote: >On Sun, 21 Jun 2009 19:08:11 -0400, Dave wrote: > >> On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: >> >> > I *wish* it made a difference. I did an upgrade am an left with a host >> > of fc10 packages because the fc11 ones weren't considered newer. >> > >> > For example people with updates-testing enabled on fc10 got a >> > non-upgraded yum because the versions were the same (except for >> > fc10/fc11) and it stopped working because python went from 2.5 to 2.6. >> >> That's messed up. We used to check just before release time that this >> situation never occured. >^ > >Even later there used to be another script that queried koji for more >accurate package release versions, but it has never been run regularly, >not even prior to the next Fedora release. Yep. It still exists and can be run. > >> It should probably be added to the rel-eng >> release checklist if it isn't there already. > >Does rel-eng have any interest at all in avoiding some upgrade path >problems? I don't see that. Running a script to catch _some_ issues would While you might not see it, that doesn't mean it doesn't exist. I used to run the script myself. Lately, I have both forgotten and had little time to do so. I can try and poke at it again. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 04:49 PM, Josh Boyer wrote: > > I think you mean "before pushing" rather than signing, but this idea has been > suggested before. Well, if you aren't going to push anyway, then signing it wouldn't be that useful, right? A koji build can be a trigger for the script check instead of a push in bodhi. The good thing is, we could possibly tie this into bodhi > during update submission. It's fairly easy to do NEVR comparisons and we > don't > need full repos for the upgrade path checks to happen since we can use the > update information and koji tags. > > The bad thing is, this suffers from the same problems every other auto-QA > suggestion has. Namely, no code, nobody with time to write the code, and it > potentially slows things down even more. Isn't the scripts Michael Schwendt refers to, not useful anymore? Even one with some false positives would be better than nothing. There is also the separate but related problem of maintainers ignoring issues that are being reported but that is a relatively smaller number. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > There are still packagers who bump %version or %release > in old dist updates without considering the consequences with regard to > dist upgrades. I think this is the real problem If this hits yum or any package yum depends on you have no chance for dist-upgrade I had the problem updating f8->f9 eith openssl-dependencies of installed yum-version which was installed in a version yum did not resolve because installed yum has dependencie of installed openssl and the yum-version from f9 was not resolved as "to update". preupgrade did leave me with a unbootable system without a kernel after second try and finally i had to force the upgrade again form dvd - if this happens on a server you would wish to die :-) I think dist-upgrades with yum should be forced official because you can not upgrade a server from dvd or preupgrade because of downtime my experience is that upgrades with yum are much better if there are no broken dependencies because you can check and fix grub.conf, make manually updates, remove leaves and so on while the system is running and as sample apache serves his websites without downtime, so you have more time to look and think before you reboot and run into troubles. anaconda is a blackbox in this case -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko/cggACgkQhmBjz394AnlfLACeJb50BGs8lSM6RtBI4XRhOV4Y RgsAnipX1IGn/9iYwt5fAD6T9o5q3pA1 =k3bM -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 04:53:10PM +0530, Rahul Sundaram wrote: >On 06/22/2009 04:49 PM, Josh Boyer wrote: > >> >> I think you mean "before pushing" rather than signing, but this idea has been >> suggested before. > >Well, if you aren't going to push anyway, then signing it wouldn't be >that useful, right? A koji build can be a trigger for the script check Right, but pushing and signing are disjoint. >instead of a push in bodhi. No, I don't think we want to do that yet. The way my brain sees it working is that a maintainer does a build and submits it into bodhi. When he/she submits it for test/stable, bodhi will run a quick upgrade path check and refuse to actually put it in the pending state if it breaks an upgrade path. The signing stuff is only done on updates that are accepted, so you don't have to worry about signing a useless build. >> The bad thing is, this suffers from the same problems every other auto-QA >> suggestion has. Namely, no code, nobody with time to write the code, and it >> potentially slows things down even more. > >Isn't the scripts Michael Schwendt refers to, not useful anymore? Even It's useful. It's generally after the fact though, and in the long run I think we want to be proactive, not reactive. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 05:35 PM, Josh Boyer wrote: >> Isn't the scripts Michael Schwendt refers to, not useful anymore? Even > > It's useful. It's generally after the fact though, and in the long run I > think > we want to be proactive, not reactive. I agree but we aren't even reacting much now. If the scripts run from infrastructure systems automatically as opposed to having someone run it manually, I suspect it would help fix most of the issues we are currently having. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 06:20:07PM +0530, Rahul Sundaram wrote: >On 06/22/2009 05:35 PM, Josh Boyer wrote: > >>> Isn't the scripts Michael Schwendt refers to, not useful anymore? Even >> >> It's useful. It's generally after the fact though, and in the long run I >> think >> we want to be proactive, not reactive. > >I agree but we aren't even reacting much now. If the scripts run from >infrastructure systems automatically as opposed to having someone run it >manually, I suspect it would help fix most of the issues we are >currently having. True. Care to file a rel-eng ticket suggesting we setup a cronjob to do so? The script will likely need some rework and it may take some time, but the ticket is a good starting point. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Le Lun 22 juin 2009 15:26, Josh Boyer a écrit : > True. Care to file a rel-eng ticket suggesting we setup a cronjob to > do so? > The script will likely need some rework and it may take some time, but > the > ticket is a good starting point. Can a ticket be opened to run other periodic checks for which scripts exist ? -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 06:56 PM, Josh Boyer wrote: > On Mon, Jun 22, 2009 at 06:20:07PM +0530, Rahul Sundaram wrote: >> On 06/22/2009 05:35 PM, Josh Boyer wrote: >> Isn't the scripts Michael Schwendt refers to, not useful anymore? Even >>> >>> It's useful. It's generally after the fact though, and in the long run I >>> think >>> we want to be proactive, not reactive. >> >> I agree but we aren't even reacting much now. If the scripts run from >> infrastructure systems automatically as opposed to having someone run it >> manually, I suspect it would help fix most of the issues we are >> currently having. > > True. Care to file a rel-eng ticket suggesting we setup a cronjob to do so? > The script will likely need some rework and it may take some time, but the > ticket is a good starting point. Here, you go https://fedorahosted.org/fedora-infrastructure/ticket/1471 Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 12:01, Michael Schwendt wrote: On Sun, 21 Jun 2009 19:08:11 -0400, Dave wrote: On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: I *wish* it made a difference. I did an upgrade am an left with a host of fc10 packages because the fc11 ones weren't considered newer. For example people with updates-testing enabled on fc10 got a non-upgraded yum because the versions were the same (except for fc10/fc11) and it stopped working because python went from 2.5 to 2.6. That's messed up. We used to check just before release time that this situation never occured. ^ No, that's not entirely true. The full story is from the book "What sucks about Fedora". There used to be regular runs of the upgradecheck.py script from the Fedora Extras era, which mailed the fedora-maintainers list (and later fedora-devel list), and later the upgradecheckspam.py script which mailed package owners directly. That helped with getting upgrade problems fixed, but it wasn't part of any release policy to make sure all upgrade path violations would have to get fixed. Then with the switch to koji+bodhi a few package owners complained loudly about false positives that were caused by pending builds, which were not found in the master repo yet. A few other package owners jumped upon the train and questioned the usefulness of the script, since they were of the opinion that breaking upgrade paths the way they did it with updates- testing and stable updates would not be considered a problem. Even later there used to be another script that queried koji for more accurate package release versions, but it has never been run regularly, not even prior to the next Fedora release. It should probably be added to the rel-eng release checklist if it isn't there already. Does rel-eng have any interest at all in avoiding some upgrade path problems? I don't see that. Running a script to catch _some_ issues would be tons better than not running a script at all. The problem is not limited to some people upgrading from F10 updates-testing to F11 without updates-testing. There are still packagers who bump %version or %release in old dist updates without considering the consequences with regard to dist upgrades. And in Rawhide? Just because a packager doesn't track Rawhide for some time should not imply that files in "devel" cvs become older than in the other dist branches or that updates for released dists get ahead of builds in Rawhide. The freeze only adds to the problem, because packagers can push upgrades for old dists while the unreleased dists remains frozen. It's also simply a crap decision if packagers quickly mark F10 updates as stable while the corresponding F11 update has not seen any testing at all (while it's stuck in the growing list of pending updates in bodhi or waiting for release of F11). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Releng and qa are interested in finding and fixing these issues. Upgrade path issues will be a part of the autoqa system. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 1:31 AM, Jesse Keating wrote: > If you have any ideas I'd like to hear them. A super epoch has already been > suggested but that just masks the problem and may cause unwanted downgrades. > Any solution either involves severly limiting what kind of updates can be > done or requiring network access during upgrades. There is a solution, although it also suffers from the "unwanted downgrades" problem, and requires such fundamental infrastructure changes that it is probably impractical. Change the way RPM compares versions: 1. The dist tag is most significant. An fc11 tag always beats an fc10 tag, regardless of version number. 2. The release tag is the least significant. This is essentially a counter, saying how many times a given package has been released for a given distribution. The upstream version number is purely informational. This means that Epoch tags are unnecessary. If you need to downgrade a package in a distribution, you bump up the release tag and bump down the version tag. On upgrade, the higher dist tag moves you to whatever has been released in the newer distribution, even if it is a lower upstream version number. This fixes the problem of upgrading from F-10 with updates to F-11 3 months after the release of F-11. However, there is no reliable way to distinguish wanted downgrades from unwanted downgrades. Bummer. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 09:31:32AM +0200, Jesse Keating wrote: > On Jun 22, 2009, at 9:26, Rahul Sundaram > wrote: > >> On 06/22/2009 12:54 PM, Jesse Keating wrote: >> >>> >>> Not possible while we allow people to keep making updates to the >>> older >>> releases. Those updates quickly become version ( not just release >>> even >>> ) higher than the static copies on the release medium and repos. >> >> Is there any proposed solution to this problem? We can't just continue >> to break upgrade paths and call it the way things are done. >> >> Rahul >> > > If you have any ideas I'd like to hear them. A super epoch has already > been suggested but that just masks the problem and may cause unwanted > downgrades. Any solution either involves severly limiting what kind of > updates can be done or requiring network access during upgrades. How about something in bodhi that checks you aren't introducing this problem, forcing you to push a higher NVR package to $nextrelease first before you can push it to updates? Considering these updates are supposed to be for our 'stable' release, having them be in $nextrelease first seems like a good idea anyway. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 8:32 AM, Dave Jones wrote: > Considering these updates are supposed to be for our 'stable' release, > having them be in $nextrelease first seems like a good idea anyway. including rawhide? Do you want security fix updates to block on rawhide not composing in order to prevent an upgrade path breakage. -jef? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Jeff Spaleta writes: > On Mon, Jun 22, 2009 at 8:32 AM, Dave Jones wrote: >> Considering these updates are supposed to be for our 'stable' release, >> having them be in $nextrelease first seems like a good idea anyway. > including rawhide? > Do you want security fix updates to block on rawhide not composing in > order to prevent an upgrade path breakage. You could work around that by using a suitable definition of "pushed". (You'd need a careful definition anyway, to not fail on an update request that's trying to push to all the back branches at once.) However, there's still an issue if rawhide is so badly broken that a package won't even *build* there, as we know happens occasionally. Maybe it would be sufficient just to have a nag reminder to the maintainer. "Pushing this would create an upgrade path breakage, are you *sure* you don't want to update $nextversion first?" I think it would be reasonable to have a hard requirement for update consistency among already-released branches, though. I find it hard to envision a situation where it'd be reasonable to push something to F9 before F10 today, say. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, 22 Jun 2009 14:18:39 -0400, Tom wrote: > Jeff Spaleta writes: > > On Mon, Jun 22, 2009 at 8:32 AM, Dave Jones wrote: > >> Considering these updates are supposed to be for our 'stable' release, > >> having them be in $nextrelease first seems like a good idea anyway. > > > including rawhide? Yes, with exceptions and creating a warning at least. See below. > > Do you want security fix updates to block on rawhide not composing in > > order to prevent an upgrade path breakage. Not really, although the same question applies also to the other dists. Theoretically it would be possible that temporary build problems with a newer dist could cause a security fix for an older dist to be blocked. (e.g. foo-2.1-1.fc10 being ready to be pushed, but fc11 being stuck at foo-2.0-1.fc11 because foo-2.1-1.fc11 fails to build due to arbitrary issues one can imagine) > You could work around that by using a suitable definition of "pushed". > (You'd need a careful definition anyway, to not fail on an update > request that's trying to push to all the back branches at once.) > > However, there's still an issue if rawhide is so badly broken that a > package won't even *build* there, as we know happens occasionally. *Then* any such package that doesn't build in rawhide and would block updates for older dists shall be put onto a special MUST-FIX list that blocks Rawhide instead, so Rawhide cannot become the next Fedora release before these missing packages have been built successfully. With regard to security issues, you either run Rawhide already and then you may be vulnerable as long as the fix can't be built. Or you use an older dist release and you can get the fix for that dist, but in case of dependency problems and violated upgrade path to Rawhide, you can't upgrade to Rawhide. Tons better than upgrade issues between stable Fedora releases. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 18:32, Dave Jones wrote: On Mon, Jun 22, 2009 at 09:31:32AM +0200, Jesse Keating wrote: On Jun 22, 2009, at 9:26, Rahul Sundaram wrote: On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. Rahul If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. How about something in bodhi that checks you aren't introducing this problem, forcing you to push a higher NVR package to $nextrelease first before you can push it to updates? Considering these updates are supposed to be for our 'stable' release, having them be in $nextrelease first seems like a good idea anyway. Doesn't actually help when upgrading from the static DVD or release repo. Updates to the new release have to be enabled at upgrade time for this to help. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Ben Boeckel wrote: > However, if you're upgrading to the DVD, yes, there will be > broken deps from updates-testing. Since updates-testing of > F(n-1) is a moving target that can pass GA of Fn's NVR set very > quickly, forcing F11 > F10 in all cases is unacceptable and > would stunt releases that aren't (Rawhide - 1). The problem is not just updates-testing. Stable updates have overrun F11 too, in fact for KDE they did before F11 was even released. Upgrading from the installer DVD, or any other method which doesn't include updates, is broken by design. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote: > If you have any ideas I'd like to hear them. A super epoch has already > been suggested but that just masks the problem and may cause unwanted > downgrades. Any solution either involves severly limiting what kind of > updates can be done or requiring network access during upgrades. Mandriva versions updates like this: 1.0-1mdv2009.1: initial package release in 2009 Spring 1.0-1.1mdv2009.1: first update 1.0-1.2mdv2009.1: second update ... and so on. Meanwhile, in Cooker (development branch), it'll be proceeding like this: 1.0-2mdv2010.0 1.0-3mdv2010.0 and so on. In addition, Cooker gets an automated rebuild of all packages at the start of each new release cycle, so in practice, packages for one release are always newer than any official update for the previous release(*). Backports can theoretically be versioned so that they'd have the update problem, but in practice it doesn't often happen (and hey, backports are unsupported anyway, you get to keep both pieces!). The problem with this method is it involves a bit more work, because you can't just send the exact same build to Rawhide and to a stable release together. I suppose it might also be a bit tough to police automatically: MDV updates are gatekeeper-ed by the security team, so this is policed manually there (if you don't version your candidate update package properly, it doesn't get sent out as an update, and you get an email telling you what you did wrong). * - except if the automated rebuild somehow failed, and that package never got touched again in Cooker before the next stable release, but did get updated in the previous stable release. I've rarely if ever seen that actually happen, though. -- adamw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Michael Schwendt wrote:
> Then with the switch to koji+bodhi a few package owners complained loudly
> about false positives that were caused by pending builds, which were not
> found in the master repo yet. A few other package owners jumped upon the
> train and questioned the usefulness of the script, since they were of the
> opinion that breaking upgrade paths the way they did it with
> updates-testing and stable updates would not be considered a problem.
The actual issue we complained about was that the script (the one querying
Koji) required Fn+1 updates to be >= Fn updates-testing which makes no
sense at all. I wrote a patch to fix that:
http://repo.calcforge.org/f10/check-upgrade-paths.py.diff
but it got lost under Jesse Keating's endless pile of TODOs. :-( And it
seems the whole code is going to be rewritten for autoqa now and nobody
cares about having a working check-upgrade-paths.py until autoqa goes
live. :-(
> It's also simply a crap decision if packagers quickly mark F10 updates as
> stable while the corresponding F11 update has not seen any testing at all
> (while it's stuck in the growing list of pending updates in bodhi or
> waiting for release of F11).
In my experience, an update which is working fine on one release has a very
high probability of working just as well on the other ones, especially if
the package being updated was working in the first place (which are the
cases we really care about - if the package was broken, pushing an update
which is broken the same way doesn't make things worse). In the updates I
pushed, I only remember one case where it didn't, which was due to improper
use (string comparison instead of numeric comparison) of dist conditionals
(by another packager, who requested that update to be added to our update
set, I'd have never made that mistake myself, though I am to blame for not
proofreading the changes). Due to bad timing, that build hit stable
directly (it got added to our Qt 4.5.0 update set just before we decided to
finally push it to stable after a long time in testing), causing a broken
dependency on F9 (which I fixed in the next push). But this was an isolated
occurrence which was due to a blatant packaging mistake (which could even
be caught by automated QA - any spec file containing "%{?fedora}" with the
quotes is broken) and which a maintainer experienced with multi-release
updates won't make. So I don't see pushing identical updates built from
identical specfiles for 2 or 3 releases at the same time as evil at all.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 24, 2009, at 0:46, Adam Williamson wrote: On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote: If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. Mandriva versions updates like this: 1.0-1mdv2009.1: initial package release in 2009 Spring 1.0-1.1mdv2009.1: first update 1.0-1.2mdv2009.1: second update ... and so on. Meanwhile, in Cooker (development branch), it'll be proceeding like this: 1.0-2mdv2010.0 1.0-3mdv2010.0 and so on. In addition, Cooker gets an automated rebuild of all packages at the start of each new release cycle, so in practice, packages for one release are always newer than any official update for the previous release(*). Backports can theoretically be versioned so that they'd have the update problem, but in practice it doesn't often happen (and hey, backports are unsupported anyway, you get to keep both pieces!). The problem with this method is it involves a bit more work, because you can't just send the exact same build to Rawhide and to a stable release together. I suppose it might also be a bit tough to police automatically: MDV updates are gatekeeper-ed by the security team, so this is policed manually there (if you don't version your candidate update package properly, it doesn't get sent out as an update, and you get an email telling you what you did wrong). * - except if the automated rebuild somehow failed, and that package never got touched again in Cooker before the next stable release, but did get updated in the previous stable release. I've rarely if ever seen that actually happen, though. That severly limits what maintainers can put out as updates. Essentially no version bumps. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Tue, 2009-06-23 at 23:46 +0100, Adam Williamson wrote: > The problem with this method is it involves a bit more work, because you > can't just send the exact same build to Rawhide and to a stable release > together. I suppose it might also be a bit tough to police > automatically: MDV updates are gatekeeper-ed by the security team, so > this is policed manually there (if you don't version your candidate > update package properly, it doesn't get sent out as an update, and you > get an email telling you what you did wrong). ..and the obvious third problem that this doesn't help when you ship a new version of the package as an official update, of course. In that case you can still get bitten by the 'old' release updates being newer than 'new' release media case. -- 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: Why do we need FC version attached to the package name?
Nathanael D. Noblet wrote: > For example people with updates-testing enabled on fc10 got a > non-upgraded yum because the versions were the same (except for > fc10/fc11) and it stopped working because python went from 2.5 to > 2.6 So to RPM the fc10/fc11 isn't being compared, at least not that > I can see... That yum update is now stable: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5328 so it is now NO LONGER POSSIBLE (!!!) and WILL NEVER (!) BE POSSIBLE AGAIN (!!!) to upgrade an updated Fedora 10 to Fedora 11 using the DVD installer without breaking yum. Only a respin can help... until the next yum update in F10! Upgrades using the DVD installer are broken by design. We got lucky until now, but this time the DVD has become completely useless for upgrades, unless you like having to fetch an updated yum by hand (which, if you are a KDE user, you have to do from runlevel 3 because KDE (including KDM) is also broken after the upgrade for basically the same reason yum is - good luck with the command-line ftp! I've had my fun fixing a relative's system that way), installing it with rpm -Uvh and then running it to fix the remaining breakage (e.g. KDE). Fedora CANNOT be upgraded with a method not including updates. We really need to fix the download page not to recommend the DVD for upgrades (and I'll ping the websites team about that). I think preupgrade >= 1.1.0 is the only solution we can officially recommend. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Jussi Lehtola wrote: > Does anaconda currently force installs of core packages such as yum? No. > This is quite important if the version in the old distro is newer than > that on the DVD. You just end up with a broken yum. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Rahul Sundaram wrote: > On 06/22/2009 12:54 PM, Jesse Keating wrote: >> Not possible while we allow people to keep making updates to the older >> releases. Those updates quickly become version ( not just release even >> ) higher than the static copies on the release medium and repos. > > Is there any proposed solution to this problem? The only solution to this particular problem is to stop claiming we support upgrade methods which don't include updates. The F11 DVD is no longer viable for upgrades as of the latest F10 yum update. We CANNOT recommend it for upgrades anymore. For future Fedora releases, there are 2 solutions: either we fix the DVD to use the repositories enabled on the installed system (updates etc.) like preupgrade now does (which also implies that it will have to refuse doing the upgrade if it can't connect to the network) or we drop support for upgrading from the DVD entirely (we could hide it behind an "upgrade" boot option like RHEL does). > We can't just continue to break upgrade paths and call it the way things > are done. There are 2 distinct issues: * upgrade paths from Fn + updates to the Fn+1 DVD. Those just cannot be maintained, we simply need to drop support for this kind of updates. If the DVD is to continue supporting upgrading, it needs to fetch updates from the network. * upgrade paths from Fn + updates to Fn+1 + updates. Those make sense to maintain. This is what the replies are focusing on. But this will not solve the original problem. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Dave Jones wrote: > How about something in bodhi that checks you aren't introducing this > problem, forcing you to push a higher NVR package to $nextrelease first > before you can push it to updates? We have to allow pushing to several releases at the same time. For example, KDE upgrades are already hard enough to coordinate as is, having to wait for the push before being able to queue the update for the previous release is not viable. That additional wait would also annoy the heck out of many packagers who just want to push their trivial fix to a single package everywhere without having to wait. Of course, if we just require a matching update for the newer release to be queued (as opposed to pushed already), that's OK, it'll satisfy the above requirement just fine. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Jussi Lehtola wrote:
> The versioning of packages with %{?dist} (.fc10, .fc11 and so on) also
> has a purpose. Different versions of Fedora use different compiler
> versions and optimization flags that are not present in older versions.
And most importantly, different versions of libraries with different
sonames. You can't use F10 KDE builds on F11 because the OpenSSL soname got
bumped.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Wed, 24 Jun 2009 01:02:18 +0200, Kevin wrote: > Michael Schwendt wrote: > > Then with the switch to koji+bodhi a few package owners complained loudly > > about false positives that were caused by pending builds, which were not > > found in the master repo yet. A few other package owners jumped upon the > > train and questioned the usefulness of the script, since they were of the > > opinion that breaking upgrade paths the way they did it with > > updates-testing and stable updates would not be considered a problem. > > The actual issue we complained about was [...] Let's not argue about memories. I referred to the earlier complaints, those about the upgradecheck*.py script and how to handle updates-testing, pending, and unreleased updates in koji. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Kevin Kofler wrote: The only solution to this particular problem is to stop claiming we support upgrade methods which don't include updates. This can't be the only possible solution to this problem. Anaconda can already ignore dependencies when installing packages which aren't part of the update set. All that would be required would be allowing it to downgrade packages which are newer on the original system to those present on the install media. The whole point of a release set of packages is that it is a well tested consistent set of pacakges. I don't see the problem with forcing the use of these packages during an upgrade regardless of what versions were on the original system. You'd be left with a functional system and the tools you need to update to the latest versions of packages should be functional. The F11 DVD is no longer viable for upgrades as of the latest F10 yum update. We CANNOT recommend it for upgrades anymore. This is certainly true, but that doesn't mean that all future updates have to be broken. I've got machines which have been stepwise upgraded from around FC3 and this is the first release where one of the core packages has been broken due to a dependency problem during the upgrade. For future Fedora releases, there are 2 solutions: either we fix the DVD to use the repositories enabled on the installed system (updates etc.) like preupgrade now does (which also implies that it will have to refuse doing the upgrade if it can't connect to the network) or we drop support for upgrading from the DVD entirely (we could hide it behind an "upgrade" boot option like RHEL does). So, just to be clear here. Anyone who either has no network connection or whose network connection is too slow to support downloading potentially hundreds of megs up updates isn't going to be able to upgrade any more? Simon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Kevin Kofler wrote: this time the DVD has become completely useless for upgrades, unless you like having to fetch an updated yum by hand (which, if you are a KDE user, you have to do from runlevel 3 because KDE (including KDM) is also broken after the upgrade for basically the same reason yum is - good luck with the command-line ftp! Actually there is a slightly simpler fix which is: su - export PYTHONPATH=/usr/lib/python2.5/site-packages yum update yum -y There was also a proposed update for F10 which (I think) altered the python path so the upgrade was not broken (the F10 yum was still present but was functional), but this didn't make it beyond Koji. https://bugzilla.redhat.com/show_bug.cgi?id=506685 This is still a bad situation to end up in, but it could have been worse! Simon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Simon Andrews wrote: > I don't see the problem with forcing the use of these packages during an > upgrade regardless of what versions were on the original system. You'd > be left with a functional system Not really. Things like KDE config files processed by kconf_update, Firefox profiles, Amarok databases etc. will have been converted to the format expected by the new version, downgrading is not supported by upstream and the old version may thus not work or lose some settings. > and the tools you need to update to the latest versions of packages should > be functional. That part should hopefully be true. Still, I wonder if it's really a valid tradeoff. >> For future Fedora releases, there are 2 solutions: >> either we fix the DVD to use the repositories enabled on the installed >> system (updates etc.) like preupgrade now does (which also implies that >> it will have to refuse doing the upgrade if it can't connect to the >> network) or we drop support for upgrading from the DVD entirely (we could >> hide it behind an "upgrade" boot option like RHEL does). > > So, just to be clear here. Anyone who either has no network connection > or whose network connection is too slow to support downloading > potentially hundreds of megs up updates isn't going to be able to > upgrade any more? Fedora effectively requires a fast network connection for the regular updates anyway. Of course the folks who need offline upgrades could use some hidden "upgrade" option and get to keep the pieces. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Le Mer 24 juin 2009 12:01, Kevin Kofler a écrit : > Not really. Things like KDE config files processed by kconf_update, > Firefox > profiles, Amarok databases etc. will have been converted to the format > expected by the new version, downgrading is not supported by upstream > and > the old version may thus not work or lose some settings. What may work is an anaconda mode that does not look up for network updates and runs yum in --skip-broken mode (and --skip-broken to be improved, right now there are still some cases where it gives up when some uprades would have been possible) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Den 2009-06-24 11:37, Simon Andrews skrev: So, just to be clear here. Anyone who either has no network connection or whose network connection is too slow to support downloading potentially hundreds of megs up updates isn't going to be able to upgrade any more? Preupgrade could install a hook that recognises distro DVDs (or even CDs) when inserted in a running system, prompting the user "Would you like to upgrade to ?", which would just run Preupgrade as usual, copying packages off the disc if possible. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: Why do we need FC version attached to the package name?
The problem is preupgrade normally pulls from release + updates, pulling from the DVD even now will not work because F10 + updates has newer file versions than are on the DVD. -Original Message- From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-boun...@redhat.com] On Behalf Of Alexander Boström Sent: Wednesday, June 24, 2009 12:16 PM To: Development discussions related to Fedora Subject: Re: Why do we need FC version attached to the package name? Den 2009-06-24 11:37, Simon Andrews skrev: > So, just to be clear here. Anyone who either has no network connection > or whose network connection is too slow to support downloading > potentially hundreds of megs up updates isn't going to be able to > upgrade any more? Preupgrade could install a hook that recognises distro DVDs (or even CDs) when inserted in a running system, prompting the user "Would you like to upgrade to ?", which would just run Preupgrade as usual, copying packages off the disc if possible. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Den 2009-06-24 20:55, Avery, David [DENTK] skrev: The problem is preupgrade normally pulls from release + updates, pulling from the DVD even now will not work because F10 + updates has newer file versions than are on the DVD. Nothing (AFAICT) prevents Preupgrade from pulling both from a DVD and from the net. That will save as much bandwidth as you save by upgrading from the DVD directly, but it will actually work. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Nicolas Mailhot wrote: > What may work is an anaconda mode that does not look up for network > updates and runs yum in --skip-broken mode (and --skip-broken to be > improved, right now there are still some cases where it gives up when > some uprades would have been possible) Then the F10+updates -> F11 upgrade will be mostly a no-op (e.g. the F10 KDE requires the old openssl which prevents upgrading almost everything else). --skip-broken is not a magic bullet, if everything's broken, it won't do much good. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Kevin Kofler wrote: Simon Andrews wrote: I don't see the problem with forcing the use of these packages during an upgrade regardless of what versions were on the original system. You'd be left with a functional system Not really. Things like KDE config files processed by kconf_update, Firefox profiles, Amarok databases etc. will have been converted to the format expected by the new version, downgrading is not supported by upstream and the old version may thus not work or lose some settings. Surely these aren't the kind of updates which should be applied within a release cycle anyway? A new release is the time you'd expect to get a major revision of this sort. So, just to be clear here. Anyone who either has no network connection or whose network connection is too slow to support downloading potentially hundreds of megs up updates isn't going to be able to upgrade any more? Fedora effectively requires a fast network connection for the regular updates anyway. Really? I've installed Fedora for several people who don't have a decent network connection and have taken updates on a USB stick at intervals. I'm sure there's plenty of the world where install disks are passed round. Even where you do have a fast network connection there can still be problems: 1) All of our servers have to access the internet via a proxy. At least within the Anaconda UI there doesn't appear to be any support for configuring proxies so I'm forced into kickstart / shells / extra boot options to upgrade? 2) At home I have a cap on how much I can download except for an unlimited window overnight (midnight - 6am I think). Do I now have to wait up to upgrade my machines rather than doing the initial upgrade from media and then picking up updates automatically the next night? Making a media based upgrade unsupported is going to be a pain for an awful lot of people. Simon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/25/2009 01:37 PM, Simon Andrews wrote: > > 1) All of our servers have to access the internet via a proxy. At least > within the Anaconda UI there doesn't appear to be any support for > configuring proxies so I'm forced into kickstart / shells / extra boot > options to upgrade? Do you have a RFE filed on this? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Le Jeu 25 juin 2009 10:07, Simon Andrews a écrit : > 1) All of our servers have to access the internet via a proxy. At > least > within the Anaconda UI there doesn't appear to be any support for > configuring proxies so I'm forced into kickstart / shells / extra boot > options to upgrade? BTW, this is one thing Intel's Connexion Manager designed right (apart from the focus on a working cli interface from the start up) : make HTTP/DNS caching/proxiing a core system-wide property, and not something "exotic" that needs to be bolted on afterwards. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Rahul Sundaram wrote: On 06/25/2009 01:37 PM, Simon Andrews wrote: 1) All of our servers have to access the internet via a proxy. At least within the Anaconda UI there doesn't appear to be any support for configuring proxies so I'm forced into kickstart / shells / extra boot options to upgrade? Do you have a RFE filed on this? No, because I've never needed this to work since our upgrades are all done via nfsiso mounts. One I can boot into the new system I use yum to get the remaining updates, and the yum proxy support works fine (well except for BZ#484491). If all anaconda upgrades are going to be online then I'd also add in the ability to configure network cards since all of our switches have only one forced mode (not my choice!) and this isn't detected correctly by the broadcom ethernet drivers. Trying to run an upgrade over a connection configured with the wrong duplex setting would be truly painful. Again I have ethtool fixes in place once the new system boots, but they're not there in anaconda. Can anaconda handle wireless network connections for upgrades? Simon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/25/2009 04:37 PM, Simon Andrews wrote: > Rahul Sundaram wrote: >> On 06/25/2009 01:37 PM, Simon Andrews wrote: >> >>> 1) All of our servers have to access the internet via a proxy. At least >>> within the Anaconda UI there doesn't appear to be any support for >>> configuring proxies so I'm forced into kickstart / shells / extra boot >>> options to upgrade? >> >> Do you have a RFE filed on this? > > No, because I've never needed this to work since our upgrades are all > done via nfsiso mounts. One I can boot into the new system I use yum to > get the remaining updates, and the yum proxy support works fine (well > except for BZ#484491). It might be good to file it nevertheless. > If all anaconda upgrades are going to be online then I'd also add in the > ability to configure network cards since all of our switches have only > one forced mode (not my choice!) and this isn't detected correctly by > the broadcom ethernet drivers. Trying to run an upgrade over a > connection configured with the wrong duplex setting would be truly > painful. Again I have ethtool fixes in place once the new system boots, > but they're not there in anaconda. > > Can anaconda handle wireless network connections for upgrades? Since Anaconda switched over to using NM, I believe this is in the pipeline. Rahul Since Anaconda -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Once upon a time, Simon Andrews said: > 1) All of our servers have to access the internet via a proxy. At least > within the Anaconda UI there doesn't appear to be any support for > configuring proxies so I'm forced into kickstart / shells / extra boot > options to upgrade? IIRC you have to do it on a repo by repo basis. At the selection screen, when the active repos are listed in the bottom half, you can click on a repo and configure proxy settings there (again IIRC). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Once upon a time, Simon Andrews said: > Can anaconda handle wireless network connections for upgrades? I think it can, for the NICs supported out-of-the-box. I haven't tried it, but I know my wireless NIC shows up on my notebook. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Thu, 25 Jun 2009, Simon Andrews wrote: Not really. Things like KDE config files processed by kconf_update, Firefox profiles, Amarok databases etc. will have been converted to the format expected by the new version, downgrading is not supported by upstream and the old version may thus not work or lose some settings. Surely these aren't the kind of updates which should be applied within a release cycle anyway? A new release is the time you'd expect to get a major revision of this sort. No. Not always and that sort of thing is up to the maintainer. 2) At home I have a cap on how much I can download except for an unlimited window overnight (midnight - 6am I think). Do I now have to wait up to upgrade my machines rather than doing the initial upgrade from media and then picking up updates automatically the next night? Well you should definitely install yum-presto so you can save a lot of bandwidth. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Den 2009-06-25 13:07, Simon Andrews skrev: If all anaconda upgrades are going to be online Anaconda upgrades initiated through Preupgrade do not require a network connection. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Alexander Boström wrote: Den 2009-06-25 13:07, Simon Andrews skrev: If all anaconda upgrades are going to be online Anaconda upgrades initiated through Preupgrade do not require a network connection. They will if one of the conditions for upgrading is going to be access to the updates repository. Simon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/26/2009 04:04 PM, Simon Andrews wrote: > Alexander Boström wrote: >> Den 2009-06-25 13:07, Simon Andrews skrev: >>> If all anaconda upgrades are going to be online >> >> Anaconda upgrades initiated through Preupgrade do not require a >> network connection. > > They will if one of the conditions for upgrading is going to be access > to the updates repository. It is not, currently and unlikely to ever be. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Fri, 26 Jun 2009, Simon Andrews wrote: Alexander Boström wrote: Den 2009-06-25 13:07, Simon Andrews skrev: If all anaconda upgrades are going to be online Anaconda upgrades initiated through Preupgrade do not require a network connection. They will if one of the conditions for upgrading is going to be access to the updates repository. Why? Preupgrade has access to the network BEFORE the anaconda run, that's the whole point. It processes the pkg lists and downloads all the needed pkgs beforehand. So the anaconda run won't need network access b/c all the pkgs are taken care of. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Fri, 2009-06-26 at 07:44 -0400, Seth Vidal wrote: > > Preupgrade has access to the network BEFORE the anaconda run, that's the > whole point. It processes the pkg lists and downloads all the needed pkgs > beforehand. > > So the anaconda run won't need network access b/c all the pkgs are taken > care of. Doesn't the anaconda run still need to grab the repodata from the repos in use, it just uses what preugprade downloaded as a hot cache for the transaction? -- 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: Why do we need FC version attached to the package name?
On Fri, 26 Jun 2009, Jesse Keating wrote: On Fri, 2009-06-26 at 07:44 -0400, Seth Vidal wrote: Preupgrade has access to the network BEFORE the anaconda run, that's the whole point. It processes the pkg lists and downloads all the needed pkgs beforehand. So the anaconda run won't need network access b/c all the pkgs are taken care of. Doesn't the anaconda run still need to grab the repodata from the repos in use, it just uses what preugprade downloaded as a hot cache for the transaction? preupgrade figures out what you need downloads the pkgs downloads the rest of the metadata then runs createrepo on the stuff it just downloaded it is a little world all unto itself. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Simon Andrews wrote: > Surely these aren't the kind of updates which should be applied within a > release cycle anyway? A new release is the time you'd expect to get a > major revision of this sort. Any KDE update can require kconf_update scripts, even bugfix releases (and we also push the minor feature releases). The Firefox profile issue is known to affect bookmarks between 3.5 beta and RC: the beta can't read the bookmarks from the RC. I'm sure it'll get upgraded to the final release in an update. And so on. > 1) All of our servers have to access the internet via a proxy. At least > within the Anaconda UI there doesn't appear to be any support for > configuring proxies so I'm forced into kickstart / shells / extra boot > options to upgrade? You can use preupgrade. It'll fetch the updates before booting into Anaconda. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
