Re: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: > Just to be clear - you're okay with writing things off as a bug in the > repo but you're unhappy saying not obsoleteing the older pkg on an > arch-change is a packaging bug? Yes, I'm entirely serious. A package should never have to obsolete an older version of itself. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: you would expect foo-1.1.i386 to be installed instead of foo-1.0.x86_64? First this is not the case we've been talking about. Noarch packages are always arch compatible to any package they replace/update. There should never be an obsolete necessary, as for other compatible arch changes (i386 -> i586 -> i686) The whole cross incompatible arch update stuff is probably better discussed on the yum list. But heh, Seth, you you brought that issue up yourself ;-P= Florian PS: Nevertheless I have my own opinion: Staying at an old version without even an (error) message is a bad idea - especially for old versions that have security issues and will most likely require libraries that are going to be updated, too (OK, this would at least create the error message). Updates across incompatible arches should only happen when upgrading from one release to another and especially then a flexible handling is desired. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Wed, 17 Jun 2009, Kevin Kofler wrote: Seth Vidal wrote: read that again? You would expect higher ver i386 to install over x86_64 ON an x86_64 box? I'd expect that too. There's certainly a reason why the current version is not available natively, if not, it's a bug in the repo. Just to be clear - you're okay with writing things off as a bug in the repo but you're unhappy saying not obsoleteing the older pkg on an arch-change is a packaging bug? I love it. Either way it's bug reports for yum for edge cases. woohoo. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Tue, Jun 16, 2009 at 8:15 PM, Kevin Kofler wrote: > Seth Vidal wrote: > > read that again? You would expect higher ver i386 to install over x86_64 > > ON an x86_64 box? > > I'd expect that too. There's certainly a reason why the current version is > not available natively, if not, it's a bug in the repo. > >Kevin Kofler > +1 Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: > read that again? You would expect higher ver i386 to install over x86_64 > ON an x86_64 box? I'd expect that too. There's certainly a reason why the current version is not available natively, if not, it's a bug in the repo. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
2009/6/15 Seth Vidal > > > On Mon, 15 Jun 2009, Rex Dieter wrote: > > Seth Vidal wrote: >> >> >>> So if you're on x86_64 >>> >>> and you have foo-1.1.i386 and foo-1.0.x86_64 >>> >>> and you run: >>> >>> yum install foo >>> >>> you would expect foo-1.1.i386 to be installed instead of foo-1.0.x86_64? >>> >>> REALLY? >>> >> >> Yes, really, imo, ymmv, and all that. >> >> > read that again? You would expect higher ver i386 to install over x86_64 ON > an x86_64 box? > > Would this actually be a problem? Assuming what Rex said yum prefers highest version first and then closest arch second. Unless the maintainer messes around with the build archs then the version on each arch would be the same and yum would keep x86_64. If on the other hand the maintiner deliberately disabled x86_64 because (however unlikely) upstream stopped supporting it then installing i386 over x86_64 in the next version probably makes more sense anyway. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, 15 Jun 2009, Rex Dieter wrote: Seth Vidal wrote: So if you're on x86_64 and you have foo-1.1.i386 and foo-1.0.x86_64 and you run: yum install foo you would expect foo-1.1.i386 to be installed instead of foo-1.0.x86_64? REALLY? Yes, really, imo, ymmv, and all that. read that again? You would expect higher ver i386 to install over x86_64 ON an x86_64 box? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, Jun 15, 2009 at 4:06 PM, Seth Vidal wrote: > No. > > Putting a note there will just need to be cleaned up when I get to fixing > that bug. > > It's incredibly minor. I'm confused. What do you want us packagers to do, change our spec files to obsolete the old arch-specific versions, or wait for yum to change? If the former, that information needs to be communicated. I thought you had indicated that you wanted the former. -- 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: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: > > > On Mon, 15 Jun 2009, Rex Dieter wrote: > >> Seth Vidal wrote: >> >>> It's not about the upgrade process. It is only about compare_providers. >>> >>> You have 3 pkgs providing 'foo' >>> >>> foo-1.1.noarch >>> foo-1.0.x86_64 >>> foo-1.0.i386 >>> >>> Which one do you pick on x86_64 or i686? >>> >>> We weight extra toward pkgs in the same arch as the running system. And >>> then the arch NEAREST to the running arch. >> >> Maybe I'm just being naive, but I'd expect a newer EVR to trump any arch >> weighting. > > really? > > So if you're on x86_64 > > and you have foo-1.1.i386 and foo-1.0.x86_64 > > and you run: > > yum install foo > > you would expect foo-1.1.i386 to be installed instead of foo-1.0.x86_64? > > REALLY? Yes, really, imo, ymmv, and all that. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, 15 Jun 2009, Jerry James wrote: On Mon, Jun 15, 2009 at 1:33 PM, Seth Vidal wrote: Yes, as I explained on irc, it's doable - but where it gets implemented (and what else it breaks) is not as obvious as an easy fix of adding an obsoletes to the pkgs which are changing arch. The bug is still open and it will get worked on but it is pressing when there is an utterly trivial solution the packager can choose. Can we put a note about this somewhere on or under https://fedoraproject.org/wiki/Features/NoarchSubpackages ? It's clear that how yum behaves in this respect differs from what some packagers expect. FWIW, my expectations were set by these, especially the latter: https://bugzilla.redhat.com/show_bug.cgi?id=189998 https://bugzilla.redhat.com/show_bug.cgi?id=192837 No. Putting a note there will just need to be cleaned up when I get to fixing that bug. It's incredibly minor. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, Jun 15, 2009 at 1:33 PM, Seth Vidal wrote: > Yes, as I explained on irc, it's doable - but where it gets implemented (and > what else it breaks) is not as obvious as an easy fix of adding an obsoletes > to the pkgs which are changing arch. > > The bug is still open and it will get worked on but it is pressing when > there is an utterly trivial solution the packager can choose. Can we put a note about this somewhere on or under https://fedoraproject.org/wiki/Features/NoarchSubpackages ? It's clear that how yum behaves in this respect differs from what some packagers expect. FWIW, my expectations were set by these, especially the latter: https://bugzilla.redhat.com/show_bug.cgi?id=189998 https://bugzilla.redhat.com/show_bug.cgi?id=192837 Regards, -- 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: Heads up: NoArch Sub Packages Feature continues
On Mon, 15 Jun 2009, Ben Boeckel wrote: A special exemption for noarch in arch compares and version differences? If it's between some arch and noarch, defer to the version checker. Yes, as I explained on irc, it's doable - but where it gets implemented (and what else it breaks) is not as obvious as an easy fix of adding an obsoletes to the pkgs which are changing arch. The bug is still open and it will get worked on but it is pressing when there is an utterly trivial solution the packager can choose. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seth Vidal wrote: > > > On Mon, 15 Jun 2009, Rex Dieter wrote: > >> Seth Vidal wrote: >> >>> It's not about the upgrade process. It is only about compare_providers. >>> >>> You have 3 pkgs providing 'foo' >>> >>> foo-1.1.noarch >>> foo-1.0.x86_64 >>> foo-1.0.i386 >>> >>> Which one do you pick on x86_64 or i686? >>> >>> We weight extra toward pkgs in the same arch as the running system. And >>> then the arch NEAREST to the running arch. >> >> Maybe I'm just being naive, but I'd expect a newer EVR to trump any arch >> weighting. > > really? > > So if you're on x86_64 > > and you have foo-1.1.i386 and foo-1.0.x86_64 > > and you run: > > yum install foo > > you would expect foo-1.1.i386 to be installed instead of foo-1.0.x86_64? > > REALLY? > > -sv A special exemption for noarch in arch compares and version differences? If it's between some arch and noarch, defer to the version checker. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAko2oUMACgkQiPi+MRHG3qThCACgsf8PKu/aJKNw1KO7vvRkN3fL KZAAl3gMbcnFvyfFykH3lUOLzzE0ndQ= =B/QM -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, 15 Jun 2009, Rex Dieter wrote: Seth Vidal wrote: It's not about the upgrade process. It is only about compare_providers. You have 3 pkgs providing 'foo' foo-1.1.noarch foo-1.0.x86_64 foo-1.0.i386 Which one do you pick on x86_64 or i686? We weight extra toward pkgs in the same arch as the running system. And then the arch NEAREST to the running arch. Maybe I'm just being naive, but I'd expect a newer EVR to trump any arch weighting. really? So if you're on x86_64 and you have foo-1.1.i386 and foo-1.0.x86_64 and you run: yum install foo you would expect foo-1.1.i386 to be installed instead of foo-1.0.x86_64? REALLY? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: > It's not about the upgrade process. It is only about compare_providers. > > You have 3 pkgs providing 'foo' > > foo-1.1.noarch > foo-1.0.x86_64 > foo-1.0.i386 > > Which one do you pick on x86_64 or i686? > > We weight extra toward pkgs in the same arch as the running system. And > then the arch NEAREST to the running arch. Maybe I'm just being naive, but I'd expect a newer EVR to trump any arch weighting. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, Jun 15, 2009 at 6:21 PM, Toshio Kuratomi wrote: > On 06/15/2009 07:19 AM, Florian Festi wrote: > > I've been thinking about proposing a Guideline that says > "header files should not be placed in noarch packages. Header files can > contain architecture specific bits. We currently do not have an > automated method for detecting whether header files are different on > different arches. When architecture specific information is encoded in > header files and the wrong architecture headers are installed, subtle > bugs can be introduced. These bugs can be made worse because the > problems can occur and disappear unpredictably, based on which > architecture the noarch package was built on." > Some specific example could be clarify the issue, because it is istintive to put noarch the header package. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On 06/15/2009 07:19 AM, Florian Festi wrote: > There is one more thing left: Noarch sub packages should - most likely - > be reflected in the Packaging and the Package Review Guidelines. I - as > a RPM developer - really don't have a opinion how the Fedora Guidelines > should look like and I also believe this is a Fedora business I should > not interfere with. Can someone interested in this topic - probably > someone in or near the Packaging Committee - please take over this issue > and lead the discussion. I will otherwise drop it from the Feature. > I've been thinking about proposing a Guideline that says "header files should not be placed in noarch packages. Header files can contain architecture specific bits. We currently do not have an automated method for detecting whether header files are different on different arches. When architecture specific information is encoded in header files and the wrong architecture headers are installed, subtle bugs can be introduced. These bugs can be made worse because the problems can occur and disappear unpredictably, based on which architecture the noarch package was built on." Can you think of anything else that should be outlawed in the Guidelines? -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
Am 15.06.2009 16:19, schrieb Florian Festi: Please check your packages[2] whether they can make use of this feature and add your changed packages to the list[3]. I have reread the list of the candidates for noarch sub packages on your list. I wan't to notifiy, that the creation of the noarch package is only possible, if there are no packages required on the package which contains a ExcludeArch or ExclusiveArch statement in the SPEC file. For example the package fedora-ksplice could be a noarch package because it's contains only two shell scripts but unfortunately ksplice which is a dependency of this package is provided only for the intel architiecture. Creating such a package as a noarch package may cause dependencies issues, because the require package will no be available on all plattforms. Best Regards: Jochen Schmitt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, 15 Jun 2009, Florian Festi wrote: Seth Vidal wrote: Other people's noarch subpackages? Shouldn't they have obsoletes in place, too? I know it's hard to grok but for all intents and purposes a arch change is A LOT like a package rename. I like to disagree. I really see no reason why an obsolete should be needed here. Sure there is information loss when switching to noarch and back but an obsolete can't fix this. I thought I had fixed the multilib behavior of yum some time ago especially for such arch changing cases and there should be test cases covering that. Looks like I need to have a look into it again. It's not about the upgrade process. It is only about compare_providers. You have 3 pkgs providing 'foo' foo-1.1.noarch foo-1.0.x86_64 foo-1.0.i386 Which one do you pick on x86_64 or i686? We weight extra toward pkgs in the same arch as the running system. And then the arch NEAREST to the running arch. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: Other people's noarch subpackages? Shouldn't they have obsoletes in place, too? I know it's hard to grok but for all intents and purposes a arch change is A LOT like a package rename. I like to disagree. I really see no reason why an obsolete should be needed here. Sure there is information loss when switching to noarch and back but an obsolete can't fix this. I thought I had fixed the multilib behavior of yum some time ago especially for such arch changing cases and there should be test cases covering that. Looks like I need to have a look into it again. Florian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, 15 Jun 2009, Jerry James wrote: On Mon, Jun 15, 2009 at 8:19 AM, Florian Festi wrote: The Noarch Sub Package Feature continues in F12. I just updated the package lists and statistics on the Feature page[1]. I want to thank all the brave package maintainers that converted some of their sub packages in the short time frame before the F11 freeze and so gave us a test run before changing a larger number of packages in F12. For package maintainer things that have been said before are still valid (surprisingly Fedora didn't change much during the freeze). -doc, language and -common packages are still the main candidates for being switched to noarch while game or other data files are typical candidates for being split into a new noarch sub package. Do you have any idea when https://bugzilla.redhat.com/show_bug.cgi?id=502401 is going to be fixed? I'm reluctant to convert any more of my subpackages to noarch while that bug persists, given what happens when people try to install the noarch subpackages that I maintain (gcl-emacs and gcl-xemacs). Sure, I could make those subpackages Obsolete their former selves, but that won't help me with other people's noarch subpackages. I've already had to upgrade several of those by hand due to this bug on my shiny new F-11 install. Other people's noarch subpackages? Shouldn't they have obsoletes in place, too? I know it's hard to grok but for all intents and purposes a arch change is A LOT like a package rename. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: NoArch Sub Packages Feature continues
On Mon, Jun 15, 2009 at 8:19 AM, Florian Festi wrote: > The Noarch Sub Package Feature continues in F12. I just updated the package > lists and statistics on the Feature page[1]. I want to thank all the brave > package maintainers that converted some of their sub packages in the short > time frame before the F11 freeze and so gave us a test run before changing a > larger number of packages in F12. > > For package maintainer things that have been said before are still valid > (surprisingly Fedora didn't change much during the freeze). -doc, language > and -common packages are still the main candidates for being switched to > noarch while game or other data files are typical candidates for being split > into a new noarch sub package. Do you have any idea when https://bugzilla.redhat.com/show_bug.cgi?id=502401 is going to be fixed? I'm reluctant to convert any more of my subpackages to noarch while that bug persists, given what happens when people try to install the noarch subpackages that I maintain (gcl-emacs and gcl-xemacs). Sure, I could make those subpackages Obsolete their former selves, but that won't help me with other people's noarch subpackages. I've already had to upgrade several of those by hand due to this bug on my shiny new F-11 install. -- 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
