Re: [PATCH] Don't write /etc/rpm/macros. (#650490)

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

 



On Mon, 8 Nov 2010, Bill Nottingham wrote:

Chris Lumens (clumens@xxxxxxxxxx) said:
This branch == rhel6-branch, if I wasn't obvious. Although, I
wouldn't argue against it on master either.

Though, I'd prefer to remove all the callers and the method entirely.

In looking, this function is called from /usr/bin/anaconda, and
yuminstall.py:doBackendSetup(), both to write the config for the
yum/rpm instance that anaconda uses. That implies that anaconda currently
sets it to prefer 32-bit binaries if a binary exists for both arches in
the transaction. Given that we set multilib_policy=best, and we compose
with ppc64 as primary, this shouldn't be an issue in any default
installation. However, if someone manually adds <foo>.ppc to their
package set (via kickstart, or whatever) this would change the behavior
they see.

Do we still want to change this in released RHEL? While it's a behavior
change, I think the current behavior (where yum preferred 64-bit packages,
but you got 32-bit binaries if you installed both) is a bit nonsensical.

I agree that the current behavior does not make sense, but since RHEL-6 is
already going, I'm going to say we hold the line and not make this change
unless it comes in as a bug.  We've seen too many instances where things we
think should be cleaned up end up surprising way too many users.  We should
change master as clumens indicated, but keep the rest of rhel6-branch
functionality as-is and only make the change necessary for this bug report.

--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux