Re: APT 0.7 for sid
On Wed, Jun 06, 2007 at 09:49:00PM -0400, Joey Hess <joeyh@debian.org> was heard to say:
> Michael Vogt wrote:
> > - support for the new dpkg "Breaks" field (thanks to Ian Jackson for
> > his work on this)
>
> Although dpkg still doesn't have Breaks support, so we still can't use
> it, AFAIK..
>
> > - automatic installation of recommends like aptitude
>
> I want to check how this will affect d-i. The Recommends tree is still
> fairly hairy/unrefined and can result in a lot of crud being pulled in.
> (See #388290. Though having them installed by default would certianly
> add pressure to fix the bogus ones.)
I'm in favor of either enabling this by default in apt or downgrading
Recommends in policy to just a "really Suggests".
What follows are my personal observations on how the use and
interpretation of Recommends has evolved.
Policy says that Recommended packages should be found with the
recommender in "all but unusual installations". Traditionally this
was interpreted to mean that "the default installation requires this
but you can hack it up to behave differently if you really want to",
and dselect implemented this by pretty much forcing you to install
recommendations.
When apt-get came along (circa 1998?), it didn't implement Recommends
at all. At the time I added Recommends support to aptitude (2001),
dselect was still fairly widely used, and new aptitude users, while
they didn't miss dselect's strong-arming them into installing recommends,
did wish that aptitude would select them by default. Once I worked
out how to handle this in a non-annoying way, I implemented pretty
much what aptitude does now: Recommendations get selected on the first
install but not afterwards.
Since then, it seems like most users have switched to apt-get and
synaptic, with hardly anyone using aptitude or dselect any more (except
inasmuch as aptitude is called by d-i). The result seems to be that
developers psychologically view Recommends as a sort of "more emphatic
Suggests" that they can't rely on the package manager actually using.
This has led to a situation where I occasionally hear things like
this statement, from a developer whose incorrect Recommendation was
being obeyed by aptitude and breaking the system:
"It's things like this that encourage me to continue using apt-get
instead of aptitude!"
The fact that I hit these every few months without actively going
out and looking for them suggests to me that there's a fairly broad
anti-Recommends sentiment out there. Either that or I'm just unlucky. :)
We should, IMO, have a single agreed-upon use of and semantics for
Recommendations. If most developers think that Recommendations are
meaningless, then maybe we should make them meaningless. But we
should not have a situation where following Policy and tradition mean
you get subjected to random sniping about your "wrong" behavior.
And I don't think that we can get people to start using
recommendations properly without having them implemented in a
widely-used package manager. We've tried that for the last 7-8 years
and the result has been a decrease in the quality of recommendations,
with the simultaneous appearance of opposition to the idea that a
package manager should follow Recommends: lines at all.
Daniel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: