Re: Preventing installation of specific packages
On 11/18/2010 07:35 AM, Tzafrir Cohen wrote:
> You want to include some but avoid others? If so, I suspect you should
> avoiding recommendations, and explicitly include the recommendations you
> want in the list of packages. Daniel recommended using apt preferences
> to make sure some packages are not installed. I presonally prefer a
> slightly different alternative:
>
> To tell aptitude: "Don't install mail-transport-agent and don't install
> kitchen-sink" make sure you have a package that conflict with both:
>
> Conflicts: mail-transport-agent, kitchen-sink
>
> To generate such a package, use equivs, or create it manually. Add that
> package (as a local package? Will that have the right effect when
> installing the previous ones?), and you're done.
I see the equivs hack cited a lot. But I think in general, pinning
individual packages at a negative priority is more elegant. If the live
system user decides to later override the conflict and install
kitchen-sink anyway, the equivs package will be removed, and the
conflict for mail-transport-agent along with it. You could make one
equivs package per conflict, but even so, you force your users to deal
with the conflict if they want to override your choice. Using
config/chroot_apt/preferences, as Daniel suggested, will only be in
effect for at build time, not also run time.
What's unclear to me from reading apt_preferences(5) is how to specify a
per-package negative pin priority regardless of source.
I had to search the net for a solution. This suggests that the
following should be possible:
#
http://serverfault.com/questions/17046/preventing-specific-packages-from-getting-installed-in-debian
Package: mail-transport-agent
Pin: version *
Pin-Priority: -1
Package: kitchen-sink
Pin: version *
Pin-Priority: -1
Though I'm not sure if 'version *' applied to a virtual package makes
any sense at all (since you can't have versioned virtual packages) and
have not tested this myself. Maybe some other wildcard is possible and
more suitable, e.g. "a release=*"? Looks like an opportunity for
improvement of the examples section of the man page. :)
Ben
Reply to: