Re: Bug#645656: network-manager in Gnome
>>>>> Jon Dowland <email@example.com> writes:
>>>>> On Tue, Nov 01, 2011 at 02:56:53PM +0000, Ian Jackson wrote:
>> We should do it when we judge that the benefits are worth the costs.
>> In this particular case the costs seem to be minimal. There isn't
>> even a direct patch-carrying cost, since the dependency is expressed
>> in our own control files.
> What should it be called: gnome-without-network-manager?
> I really don't like evolution. Can I have a gnome-without-evolution?
> (Only half-joking. I *really* don't like evolution).
> Where do you draw the line?
> (Of course, any Debian developer can freely create such a dependency
> package, it doesn't have to be the GNOME maintainers.)
> In case it isn't clear, I don't think it's a good idea.
Well, I seem to jump into the discussion without thoroughly
reading all the postings (and I've never tried to install the
gnome package, BTW), but the issue with network-manager seems to
me much easier to solve than the one with evolution, as the
former is in Recommends:, while the latter is in Depends:.
The difference is that there could be a «negapackage» (marked as
manually installed with APT), with the sole purpose of having a
Conflicts: network-manager line. (Why, such a package could
simply be done with equivs!) Then, it was my understanding that
APT will instantly remove network-manager (and its respective
dependencies) should the negapackage be installed, and will
never try to install the offending package until an explicit
Therefore, I'm curious if the Debian metapackages could be
switched to primarily use Recommends:, and not Depends:? (So
that the users could then have a conflicting package installed,
or simply remove the offending package manually.)
FSF associate member #7257