On Ma, 17 iul 12, 12:35:20, Steve Langasek wrote: > > > 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. Yes, a general policy would probably address my question. > 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. I fully agree, and this (plus Ian's answer) is pretty much what my own impression is and what I had expected. But this is not reflected in user or developer oriented documentation (except Policy, of course). I'll be filing (wishlist) bugs for debian-reference, apt (apt-get(8)), aptitude (aptitude(8)) and so on. > > 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. My intention was for you to give Maintainers a sort of backup for cases where others may disagree with a weaker dependency. > > 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. Sure, leaving some space for individual Maintainers makes sense, but "significant amount of functionality" is quite wide. Wouldn't something like "to function properly" be better? (I'm sure this has been debated a lot, so I'll be researching this on first occasion. Would appreciate some bug numbers though if you have them handy) > > 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. Ok, I've just found #655483, I'll be following that. > > 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 think it makes sense to wait for the resolution to #681834 before discussing this any further. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Attachment:
signature.asc
Description: Digital signature