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.
2009/6/15 Seth Vidal skvi...@fedoraproject.org
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?
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
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
Hi everyone!
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
On Mon, Jun 15, 2009 at 8:19 AM, Florian Festiffe...@redhat.com 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
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
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
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
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
On Mon, Jun 15, 2009 at 6:21 PM, Toshio Kuratomi a.bad...@gmail.com 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
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
-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
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
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
15 matches
Mail list logo
