[Spacewalk-list] Package collision questions

Fri Jan 22 22:36:11 UTC 2016

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>
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] *On Behalf Of *jeff macfarland
> *Sent:* Friday, January 22, 2016 1:04 PM
> *To:* 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), all are the same minus a
> different signing date.
>
>
>
>
>
> On Fri, Jan 22, 2016 at 11:25 AM, Kalchik, Jeffery <
> 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
> 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
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160122/897a192f/attachment.htm>