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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/aanlkti=j=m-wt=1o�[email protected]
