Re: Preventing installation of specific packages
The pinning idea is probably the best approach for me, if it works, so
thanks Ben :)
If anyone is interested, the reason that the "manually install all
recommends" approach is bad for me is that (a) the number of
recommends I don't want is less than a tenth of the number I'm fine
with keeping, and (b) it completely throws out any kind of dependency
management.
By (b), I mean that if I manually install "toaster" because
"microwave" recommends it... well, firstly I have to find that out for
every single package I *do* want to manually install, which is not fun
(especially since that group now includes dozens more packages), but
more to the point, if I decide a week later that I don't want
"toaster" in my live build... can I remove "microwave" too? Or do
other packages recommend it and I should keep it around? If I remove
it... what else can I remove now? There's no easy way to tell — on a
running system, I could just do something like "aptitude search
~i~Brecommends", but I can't do that on a list of packages in my live
build config.
(Incidentally, it's not just about my hatred of MTAs or unwanted
cruft... the libc6 package recommends libc6-i686, which will trigger a
kernel panic on the 486-like machine this live build is intended
for... so I should throw out all recommends dependency management for
that? No thanks...)
I realise that this is an edge case, and it represents significantly
more control than most users ever want or need, but since people
thought it was a strange thing to ask, this is why :P
Cheers,
Jason
Reply to: