[Spacewalk-list] Package collision questions

Tue Feb 2 17:12:51 UTC 2016

Unless I’ve done something wrong (not the first time, & won’t be the last, I’m sure,) the fix listed in the first bug doesn’t appear to work in my environment.

Jeff

From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Kalchik, Jeffery
Sent: Monday, January 25, 2016 7:13 AM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Package collision questions

I haven’t.  Might be able to get to test it this week.

Jeff

From: spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com> [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of jeff macfarland
Sent: Friday, January 22, 2016 4:36 PM
To: spacewalk-list at redhat.com<mailto:spacewalk-list at redhat.com>
Subject: Re: [Spacewalk-list] Package collision questions

It is "interesting", yes. I would like to fold in to something that depends less on having a specfic minor version. Can be time consuming to keep things in line with new releases.

But did you use the suggested fix from the first bug? Sounds more appropriate that my (apparently) corner case of having empty base channels.

On Fri, Jan 22, 2016 at 1:35 PM, Kalchik, Jeffery <JDKalchik at landolakes.com<mailto:JDKalchik at landolakes.com>> wrote:
I can show a couple of dozen collisions in every distribution tree.  Fortunately, the majority of those don’t affect my kickstarts.  When it does, I figure out which package I want to use, & remove the conflicting package[s].

Historically, I’ve depended on digging through the kickstart logs.  I still will probably have to do that, but the Perl script will help tremendously in figuring out what other channels & packages are also affected.  I’ll also have to update the channel cloning configuration files to blacklist the problem packages.

Looking at your Bugzilla submission, you run a little different than we do, you have to maintain multiple minor releases, we only maintain the major versions.  I.e. only CentOS 7.2, not CentOS 7.2 and 7.0.  That’s an interesting method of controlling minor versions, though.

Thanks for the input.

Jeff

From: spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com> [mailto:spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com>] On Behalf Of jeff macfarland
Sent: Friday, January 22, 2016 1:04 PM
To: spacewalk-list at redhat.com<mailto:spacewalk-list at redhat.com>
Subject: Re: [Spacewalk-list] Package collision questions

I've run into this more than a couple times. Two fixes I am aware of

https://bugzilla.redhat.com/show_bug.cgi?id=1076490
https://bugzilla.redhat.com/show_bug.cgi?id=1287829
I submitted the latter but haven't tried out a nightly build so I am just waiting for the next release to see if it fixed my particular issue. In the meantime, I am resigned to removing an offending package manually and filtering out from the sync (typically on an updates channel). This works for me because I don't care which package is used. For the conflicting packages I've seen (all from centos.org<http://centos.org>), all are the same minus a different signing date.

On Fri, Jan 22, 2016 at 11:25 AM, Kalchik, Jeffery <JDKalchik at landolakes.com<mailto:JDKalchik at landolakes.com>> wrote:
Good morning, all.

I have a long standing situation that isn’t showing any signs of improvement.  In short, I have a number of situations where a particular package name exists with multiple checksums & backend .rpm files.

Some background:

I have 5 major release trees (base channel and child channels) in Spacewalk (2.4,)  CentOS6, CentOS7, Oracle Linux 5, Oracle Linux 6, and Oracle Linux 7.  The release channels have all been created through spacewalk-common-channels.  I also have some extra child channels in each tree for things like a local utilities channel and application channels.  Each release tree is cloned into development, QA, & production trees.  All client systems are registered to a dev, QA or production tree, never to a release tree/channel.

A package may exist in multiple channels in a tree, downloaded from separate repositories.  This can cause problems during a kickstart, when a package with a different checksum gets sent down to anaconda.  To make things worse, the kickstart problem does not always occur.   I also suspect that it could be an issue in spacecmd, as commands like ‘package_remove PKG’ don’t allow me to specify which package to remove.  Yes, ‘softwarechannel_removepackage PKG’ helps, I do limit each channel to a single repository, there shouldn’t be any collisions within a given channel.

Here’s an example.  I’ve written a Perl script to spin through the base channels, generate the channel list for that tree, & find all packages with multiple IDs and checksum.

librepo-1.7.16-1.el7.x86_64
128863  centos7-x86_64,dev-centos7-x86_64,prod-centos7-x86_64,qa-centos7-x86_64
136116  dev-epel7-centos7-x86_64,dev-epel7-oraclelinux7-x86_64,epel7-centos7-x86_64,epel7-oraclelinux7-x86_64,prod-epel7-centos7-x86_64,prod-epel7-oraclelinux7-x86_64,qa-epel7-centos7-x86_64,qa-epel7-oraclelinux7-x86_64

Rather obviously, this output lists all channels where that particular package ID exists.  (might be a good script enhancement to limit the channels to only this particular tree.)

Package 128863 has been downloaded from the CentOS7 repository.  Package 136116 has been downloaded from the Fedora Project’s Extra Packages for Enterprise Linux.  Both packages should be perfectly valid, but built by 2 different organizations and due to different build environments, have different checksums.

Is this an issue for anyone else?  How have you addressed this?

Jeff Kalchik
Systems Engineering
Land O’Lakes

This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list

This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list

This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160202/9c67e757/attachment.htm>