Hi Andrei,
On Mon, Jul 16, 2012 at 05:03:54PM +0300, Andrei POPESCU wrote:
> Given the above and also the recent problems in fitting the two major
> Desktop Environments on only one CD each it would probably help if the
> Technical Committee would take some official position on the following:
> 1. Is running a system with Recommends turned off a supported
> configuration?
I don't think it's really useful for the Tech Ctte to try to declare whether
or not something is a "supported" configuration. What is supported is up to
the individual maintainers or to Debian as a whole.
It would better fit within the scope of the committee to ask whether a
particular package relationship should be a Depends or a Recommends, or what
the policy should be for use of Depends vs. Recommends generally.
I do have a definite opinion of my own on this question. If you are
applying --no-install-recommends to your entire system, you are working
contrary to the intended purpose of Policy, which says:
The `Recommends' field should list packages that would be found
together with this one in all but unusual installations.
To avoid the installation of *all* recommends by default is to ignore the
purpose of recommends: namely, to list packages that *should* be installed
by default, but that the admin *may* remove from the system /if they know
what they're doing/. The admin who ignores all recommends and leaves them
off the system can't possibly know what they're doing; they're not making an
informed decision that the Recommends are not needed on their installation.
So an admin who has passed --no-install-recommends to apt should not be at
all surprised if some functionality they care about is missing.
> It seems quite a few Debian Developers consider this rather a supported,
> normal configuration, and not a customized, special purpose one.
> Apparently, as a consequence, there is a tendency of having stronger
> than necessary package relationships.
The TC could certainly rule on specific cases of this if asked. But the
debate about whether --no-install-recommends is sane is a very old one, and
I don't think the TC giving a position statement on this is likely to
influence those who insist on ignoring the meaning of policy.
> Based on this rationale, packages should not use Depends unless the
> given package as provided by Debian is unusable (e.g. it would crash)
> without the depended package. An obvious example would be an application
> and it's libraries.
I think there is flexibility here in how the maintainer draws the line
between Depends and Recommends. "is unusable" is not exactly the line that
Policy draws.
The `Depends' field should be used if the depended-on package is
required for the depending package to provide a significant
amount of functionality.
There's a certain amount of maintainer judgement inherent in this
definition, which I think is appropriate.
> Circular Recommends (or Depends/Recommends) relationships should also be
> avoided if technically feasible, as this renders the autoremoval feature
> of package managers almost useless.
That would be a bug in the package manager's detection of auto-installed
packages, nothing more.
> If you agree that by disabling Recommends the system administrator
> assumes responsibility for the lack of possibly important
> functionality that may even lead to breakage (e.g. rsyslog only
> Recommends: logrotate), this may need a coordinated effort to
> write/adjust some documentation (manpages of package managers, Debian
> Reference, Developer's Reference, Release Notes and possibly others). I
> am willing to help in this regard as much as time allows during the
> following release cycle.
What documentation, specifically, do you see that needs adjusting here?
Debian Policy is IMHO already quite clear on this, and all other maintainer
documentation is secondary to policy.
> 2. Are Depends appropriate for metapackages?
Given the way you've worded the question here, I think the answer is
definitely "yes".
However, I think that Recommends are *also* appropriate for metapackages.
I don't see anything in the nature of metapackages that exempts them from
the usual process of considering which of the dependencies are hard
dependencies vs. soft dependencies. Indeed, metapackages in Ubuntu are
maintained in exactly this fashion:
$ apt-cache show ubuntu-desktop | grep Depends | wc -w
82
$ apt-cache show ubuntu-desktop | grep Recommends | wc -w
125
$
For the *specific* case of a gnome metapackage, whose purpose is to install
the gnome system as defined by upstream, I think it's reasonable for the
maintainer to choose to mark as dependencies those packages which are
considered required components of the upstream GNOME system, even when many
Debian users would prefer not to install them.
The problem as I see it is not that the metapackage is constructed wrong,
but that people have differing expectations of what that metapackage
represents. It's perfectly fine for users to want a convenient way to
install the GNOME desktop while excluding the parts of it that they don't
want; however, there's no reason that a) such a metapackage should be called
'gnome', or b) the GNOME package maintainers should be the ones to maintain
this, if their goal is to deliver the complete GNOME desktop as defined by
upstream.
Now, we might also decide that this metapackage is not the right thing for
Debian to install as its default desktop. I believe that to date, the
installer team have delegated the decisions about what to include in the
default desktop over to the GNOME team. If we think that this metapackage
gives the wrong behavior for a default Debian desktop, we might replace it
with a different one - perhaps one that the GNOME team would be willing to
maintain and keep synchronized with the existing package, but under a
different binary package name.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature