[Spacewalk-list] libxml2-python and kickstart

[Jan Hutař]

On Mon, 3 Jun 2013 23:41:14 +0000 Faye Salwin
<Faye.Salwin at betfair.com> wrote:

> Centos6 updates contains libxml2-python and Spacewalk pulls
> THAT version (as it is the latest available version within any
> child channels of the selected distribution) of the RPM when
> building kickstart files instead of a package from a channel
> enabled for kickstart (The Java code pulls these files using
> the "file download url")
> 
> This works:
> http://x.x.x.x/download/package/2ca68cda56a77523c946e69ca5dc8d34e0f45f01/0/1/885/libxml2-python-2.7.6-8.el6_3.4.x86_64.rpm
> http://x.x.x.x/download/package/1e2379d4dadc3fef16c422d3aa705ff83264b469/0/1/5811/pyOpenSSL-0.10-2.el6.x86_64.rpm
> http://x.x.x.x/download/package/704fdbe78c79726bab6d1e5f8461045ef7f0a194/0/1/11132/rhnlib-2.5.55-1.el6.noarch.rpm
> rpm -Uvh --replacepkgs
> --replacefiles /tmp/rhn_rpms/optional/pyOpenSSL* /tmp/rhn_rpms/optional/rhnlib* /tmp/rhn_rpms/optional/libxml2-python* 
> 
> If the Updates repo is disabled in the kickstarter, but
> available as a child channel of the install tree, then
> libxml2-python fails to install as it cannot supply the
> dependencies to libxml2-python (*12-el6_4*) which are in the
> Updates repo too.
> 
> I have read that one shouldn't enable the Updates Repo during
> Kickstart, but if I do not delete libxml2-python from the
> updates repo then a kickstart which does not include the
> updates repo will fail.  If I do install the updates repo to
> kickstart then it will lag the install for a long time while
> it tries and retries to access a comps file which does not
> exist. (there are comps files for EPEL and Spacewalk which I
> have to include during kickstart to install the rhn_client,
> rhncfg-client etc.  I have restricted EPEL to only those
> packages which the Spacewalk repo depends upon.  I believe
> that the kickstart will continue to function from the time
> that libxml2-python from updates is added until the kickstart
> profile is updated at which point it will re-evaluate the
> includes.  It doesn't seem like a good solution to delete
> libxml2-python every time you update kickstart and then
> re-sync.
> 
> What is the best practice here?  Should I kickstart from a
> tree with updates present?  What happens about the Comps
> (groups file) in this case?  I've also noticed that cloning
> child channels (using the manage channel lifecycle script at
> least) does not clone the RHNCHANNELCOMPS row that is relevant
> which caused me a few frustrations early on.
> 
> Is it not possible to kickstart just one distribution &
> channel selection and then switch parent channels at
> activation time?  That would simplify a lot of the workflow
> (perhaps allow you to have a single kickstart for all your
> lifecycle locations and validate that the parent channel is a
> clone of the one you are activating?)
> 
> Why does the Kickstart file create java code include files
> that are from repos not included in the kickstart channels?  I
> am guessing it is so that you don't have to include the
> spacewalk repo as a child, but if you don't do that, it can't
> find rhnreg_ks for example (unless you use one of the many
> workarounds that have been posted in this list eg. tar ball of
> spacewalk files)
> 
> It is entirely possible that I am just "doing it wrong" in
> which case a pointer to best practice would be appreciated.
> 
> Thanks
> 
> 
> Faye

Hello,
you should kickstart with only base channel enabled (ideally no
additional child channels/repos). After install you can assign
additional child channels and update your system (you can assign
these channels using activation key in your kickstart profile).

If you have kickstart profile with base channel only and
satellite generated these "http://..." download links pointing
to packages which are not in the base channel, that is a bug and
please report it to the Bugzilla or here.

Regards,
Jan



-- 
Jan Hutar     Systems Management QA
jhutar at redhat.com     Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130610/bb804986/attachment.sig>