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: [email protected] [mailto:[email protected]] On Behalf Of jeff macfarland Sent: Friday, January 22, 2016 1:04 PM To: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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 [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
