Hi all,
I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I add the packages to the exclude list in the fedora repo so I don't get x86_64 versions that are newer than the left behind i686 versions. This means that my disks will have less i686 stuff than was released originally by The Fedora Project. I could just carry the updated packages in a local repo, thereby preserving the original package list. Does anyone know which is the best approach?
TIA.
On Wed, 2009-12-30 at 00:05 -0700, William F. Acker WB2FLW +1 303 722 7209 wrote:
I've always noticed that when a package is updated, sometimes the
i686 version isn't put into the x86_64 repo for updates.
Can you clarify what you're asking here? It sounds like you're saying you expect the x86_64 repo to contain i686 packages?
Jon.
On Thu, 31 Dec 2009, Jon Masters wrote:
On Wed, 2009-12-30 at 00:05 -0700, William F. Acker WB2FLW +1 303 722 7209 wrote:
I've always noticed that when a package is updated, sometimes the
i686 version isn't put into the x86_64 repo for updates.
Can you clarify what you're asking here? It sounds like you're saying you expect the x86_64 repo to contain i686 packages?
Um, -- well- -- yes. It always does. My concern is that when packages are updated, and there is an i686 and x86_64 version in the original release tree, the updates tree only has the x86_64 version, which is why I ask the question of how to handle it. I could make sure that only the x86_64 version of the package appears on the release I'm spinning, or should I make sure that the updated i686 package is carried to my release if it was present in the original release by Fedora. I hope this clarifies my concern.
On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote:
I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I
Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out.
On Mon, 2010-01-04 at 11:11 -0500, Mike McLean wrote:
On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote:
I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I
Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out.
Multilib set is dynamically determined each compose. If the package itself changes in a way that no longer triggers the multilib algorithm, then it will fall out of being multilib.
On 01/04/2010 11:32 AM, Jesse Keating wrote:
Multilib set is dynamically determined each compose. If the package itself changes in a way that no longer triggers the multilib algorithm, then it will fall out of being multilib.
Is there a mechanism to remove 'fallen' multilib packages? If not, couldn't there be update errors? For that matter, what if the lingering older multilib package contains a security flaw?
My apologies if this has been discussed to death elsewhere.
On Mon, 2010-01-04 at 18:08 -0500, Mike McLean wrote:
Is there a mechanism to remove 'fallen' multilib packages? If not, couldn't there be update errors? For that matter, what if the lingering older multilib package contains a security flaw?
My apologies if this has been discussed to death elsewhere.
It is not often that this situation happens, and usually we take a second look at the type of update going in, and whether or not it would be suitable as an update to a stable Fedora release. Alas we cannot always detect this before the push goes live (autoqa will fix this, I hope).
I do not know if the stale multilib version gets cleaned up or not. I think there is some code to handle it at anaconda upgrade time where this type of scenario is more likely to occur.
On Mon, 4 Jan 2010, Mike McLean wrote:
On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote:
I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I
Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out.
Just since F12: java-1.6.0-openjdk, gcc, gcc-gfortran, libgfortran, libgomp and cpp More to come, I'm sure.
buildsys@lists.fedoraproject.org