Bug#548661: dpkg: Override package dependencies
reassign 548661 apt
thanks
>> But as seen in bug#542095, some dependencies are not really hard, yet
>> you don't want them to be "recommends" because that would be too easy
>> for users to ignore. So bug#542095 shows that there is a need for
>> something between "recommends" and true dependencies that can only be
>> ignored if the user very specifically requests to ignore this precise
>> dependency (I already ignore all recommends).
> I don't agree that we need something in between. You decide what you want
> to install. the gnome meta-packages doesn't correspond to what you want?
> don't install it and install the various components by hand or create an
> alternative meta-package.
While it's not too difficult to install some of the components by hand
("aptitude show gnome" makes it easy to see which components are
needed), doing it leads to lots of headaches in the long run, since when
new components come around, nothing will tell you about it (and even
less install them for you), and when old ones become replaced or
obsolete, agai nobody will tell you (and even less install the
replacement for you).
That's what the `gnome' package is for, and that's why it's important to
be able to install that package (and other metapackages) rather than
its dependencies.
> You come up with this request only because Josselin Mouette doesn't
> want to drop network-manager to a Recommends or put an alternative
> in place.
Actually, no. It's a kind of problem that has shown up several times
already in the past, for various reasons. Sometimes it's just a bug in
the packaging other times the maintainer has good reasons to keep the
dependencies in a particular way, even if they don't fit my needs.
Clearly, the current network-manager-in-gnome issue is the one that
prompted this bug-report, but only because it finally occurred to me
that a good solution to this problem is a more general solution that
gives more power to the end-user.
> The solution exists but because the maintainer doesn't want to
> implement it, you request a third way to respond to your need under
> control of the user. How is that reasonable?
Because in the world of Free Software, last I heard, giving more control
to the end user is generally considered a good thing, so she doesn't
have to rely on the goodwill/agreement/help of "the men in charge".
>> What alternative solution do you propose if I want to both have wicd
>> and gnome installed? Or if my system is memory constrained and
>> I want xserver-xorg installed but not hal? Or ...?
> gnome is not required at all, it's only a meta-package, don't install it
> but install manually all the other dependencies.
> For the xserver, talk to the X maintainers or use a lighter distribution.
So for each problem in the packaging dependencies, you advocate to use
a different solution, each one of those with its own set of problems.
Instead, I advocte a single solution that can solve each one of those
problems in a uniform manner: tell the packaging system (I originally
thought dpkg would be a good place for that, but I now realize that APT
is a better place for it) about some constraints that need to be
ignored. This could include not only Dpends-constraints (as suggested
originally in this bug-report), but also Conflicts-constraints (e.g., so
I can install grub-pc, grub-efi-amd64 and and grub-efi-ia32 on my Debian
rescue USB key).
Clearly, ignoring such constraints is risky business (not like ignoring
"recommends" constraints), so you'd want to force the user to think hard
before doing so, and you'd only let her ignore specific constraints,
you might ask for confirmation before adding such an ignore-constraint
to the list of ignored constraints, and you might even query the user
every once in a while to make sure she still wants to keep those
ignore-constraints.
Stefan
Reply to: