[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Better ExactArch in yum (was: Re: Why aren't aspell-XX packages noarch?)

seth vidal wrote :

> > Which raises another point : I really hope Seth implements a kind of
> > "ExactArchPkgs=kernel kernel-smp glibc" configuration quickly to yum
> > "TNG":-)
> So, a good question came up today on discussion about this option.
> How do we add new items to this list.
> let's say in the middle of fc3 an updated packages come out and .i386
> and .i686 packages are made.
> for some misc reason - I'm sure we can all make one up.
> and that package is not listed in ExactArchPackages
> So it migrates up to .i686
> now, what if that is NOT the desired behavior?
> How do we update that config field for that contingency?
> We're still talking about manual intervention, either way.
> I'm just trying to sort out a situation where I'm not fixing one problem
> and making another one.

Well, if that's not the desired behavior, but doesn't render the system
impossible to boot, it's not such a big deal IMHO, since in the vast
majority of cases, having the "highest possible compatible arch" will be
what is wanted, and in the case of "both i386 and i686 were available... we
realized that the i686 specific version brought nothing more, so we only
provide i386 from now on", we will also want to update from the older i686
to the newer i386, no? Not to mention the arch to noarch case because it
makes more sense for the package (typically the aspell-XX dicts), or the
other way around.
The only reason the whole ExactArch thingy was brought in the first place
was because repositories where the i686 glibc update wasn't included but
the i386 one was badly broke clients updating from there (IIRC my server
suffered from that, but because you had a mirror problem on at dulug from
where I was syncing ;-)). Apart from glibc, I don't think there are other
packages that can badly break a system (from the top of my head) if
"downgraded" arch-wise, not even the kernel. And from my experience,
ExactArch has been a blocker in quite a few situations, like the
"filesystem" package which once was noarch and is now arch specific, or
multimedia libs initially packaged as i386 _and_ i686 with the i686 build
later dropped.

Anyway, just my point of view : Having a short simple default for some kind
of ExactArchPackages should suit the vast majority of users.


Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Red Hat Enterprise Linux AS release 3 (Taroon) - Linux kernel 2.6.8-1.521
Load : 0.14 0.20 0.14

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]