How to restrict package installation to x86_64
John Morris
jman at ablesky.com
Sat Feb 23 17:08:56 UTC 2008
Hi, folks, thanks for the good suggestions. I'm following up on them as
time allows.
> Given the importance of libc.so to pretty much everything, it would stand to
> reason that excluding it would prevent any apps from installing ... but then
> you can tell Kickstart to pull dependencies during installation, so that
> could undo the exclusion.
And pulling the dependencies back in is exactly what happens,
unfortunately. I put this in my kickstart.cfg file under %packages:
>> %packages
>> glibc.x86_64
>> -glibc.i386
but that later i386 packages drag the glibc.i386 package back in:
[root at sandbox ~]# rpm -qa --qf '%{name}-%{arch}\n' | grep "glibc-[xi]"
glibc-x86_64
glibc-i686
>> does everything require glibc as a dependency? If not could some other
>> key package by excluded?
>>
I think most non-'noarch' packages do depend on glibc. But
unfortunately those are the ones that drag glibc.i386 back in.
>>> I don't know if there's a way to globally restrict packages the way you're
>>> looking for, but if it suits your purposes, you can write something like
>>> this in the '%packages' section of your ks.cfg:
>>>
>>> %packages
>>> @ Admin
>>> myfoopackage.x86_64
>>> -myfoopackage.i386
>>>
Putting the specific unwanted packages into my ks.cfg file would
certainly work, but would require me first to figure out which package
is dragging in all the others, or else to put all i386 arch packages
into my ks.cfg file. I'm trying to find a way that's more maintainable
and less messy.
>>> What about removing all of the i386 rpms from your install source?
So, after saying I wouldn't take this approach in the previous mail,
this may turn out to be the easiest thing to do. We do have our own
mirror of the repos we use (the fastest non-local mirrors from Beijing
are just painfully slow...). In our nightly cronjob that brings down
the updates, we can just add an option to rsync to ignore all files
ending with .i?86.rpm, and put in an extra 'createrepo' line.
Thanks again for the suggestions. I'm a bit disappointed that kickstart
doesn't have a simple mechanism to achieve this. It appears that yum's
'exclude' option may help with this after kickstart. I would think that
some folks might have legitimate reason to want this.
My 'legitimate' reason, again, is simple laziness. I've been getting my
systems under configuration control with bcfg2, and when there are two
packages of the same name but different architecture there, I have to
type three extra lines per package to tell the system that that's OK.
I'm definitely going to take this up with bcfg2's author, of course, but
it seems that the problem stems from kickstart.
John
More information about the Kickstart-list
mailing list