On Sun, Feb 09, 2014 at 02:50:40PM +0800, Paul Wise wrote: > Please start a document on the wiki about this. May I ask why? Not that I am horribly against it, but the format is supposed to be documented in the equivalent of sources.list(5), so adding another place makes me fear that it could become out of date easily for a benefit I don't see at the moment. > Option to block the transition of packages between unrelated repos; > don't want the skype repo to replace libc6. Theoretically easy, just let the default pin only apply to the mentioned packages and give the repo a -1 instead. It is a bit harder in practice: Like, what will the interface be for users if you have a hardcoded list of packages the repo can provide, but one of those has a new dep. With pinning this is already a not so nice situation. Also interesting: What would happen if the users combines such a setting with a preferences file… I wonder if it wouldn't be better to instead improve selection possibilities of packages via pinning. I have the frequent dream of merging back (at least some) aptitude patterns… > Option to disable maintainer scripts for repos that don't need them or > shouldn't be trusted to have them. Before we can even think about that, dpkg needs an option for that. It got a lot better with triggers, but we still have a lot of maintainer scripts including boilerplate stuff created by dh_*, which frankly shouldn't be there but in a declarative file interpreted by whatever… (A simple IAmALibrary: yes → call ldconfig would remove 1000+ postinsts and postrm each on the system I am writing this mail on for example) (as usual, that isn't a proper security thing as it isn't that hard to do potentially bad stuff via dropping a file somewhere to let something else pick your evil code up like cron/$init/$shell-completion/…) Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature