Bug#688772: gnome Depends network-manager-gnome

Josselin Mouette joss at debian.org
Sat Oct 6 07:41:53 UTC 2012


Le vendredi 05 octobre 2012 à 22:07 -0600, Bdale Garbee a écrit : 
> I personally believe that metapackages should be primarily populated
> with Recommends, with Depends largely reserved for actual technical
> dependencies between real packages.

This point is probably worth discussing because it comes up very often.

I don’t think it is reasonable to do so until metapackages are treated
differently by APT.
1. Removing them should not mark their dependencies autoremove.
2. A major upgrade (which is something that needs defining, especially
for testing/unstable users) should try to reinstall all dependencies or
ask, one way or another, whether the administrator still wants to
exclude them.
Basically this means going back to a tasks system from the current
metapackages situation (whether the implementation is based on packages
or not).

> This is consistent with my belief
> that we should try to empower our users to be able to exercise a
> reasonable amount of choice in configuring and operating their Debian
> systems.

Most of the time packages get removed, it is due to upgrade problems,
with APT not choosing the best solution. Strict dependencies alleviate
most of these problems.

Maybe you are unfamiliar with what clueless newbies do with their
systems. You want to empower users, that’s fine; but GNOME is for all
users. Those who have the technical knowledge to handle their packages
manually should also know how to make it happen without metapackages.

> Thus, my bias is to believe that when there's no strong
> technical need, a Recommends is the appropriate choice, 

The purpose of a metapackage is to install all packages related to a
certain environment or functionality class. Let us not forget that when
choosing technical solutions.

> and any change
> From a Recommends to Depends causes me to want to understand why the
> change was made and what we hope to gain from it.

What has changed since lenny is that NM has been rearchitectured and is
easy to disable. You cannot even treat it like it was the same piece of
software.
Therefore, this change was supposed to happen in squeeze, but we already
delayed it at that time because of upgrades from lenny, and because the
configuration format for system connections was still new and thus
unfamiliar to many.
If we delay it once again, what do we do for jessie?

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




More information about the pkg-gnome-maintainers mailing list