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@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
_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list