On Wed, Jun 06, 2007 at 09:49:00PM -0400, Joey Hess <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]