[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: alternative dependency ordering - with respect of packages in main

On September 22, 2011 02:50:25 AM Gerfried Fuchs wrote:
> * Bruce Sass <bmsass@shaw.ca> [2011-09-21 23:18:54 CEST]:
> > On September 20, 2011 02:24:33 PM Stefano Zacchiroli wrote:
> > > On Tue, Sep 20, 2011 at 01:12:37PM +0200, Gerfried Fuchs wrote:
> > > >  tl;dr - what do you think, is a "Depends: foo-contrib | foo"
> > > >  acceptable
> > > > 
> > > > for packages in main or should it be "Depends: foo | foo-contrib"
> > > > instead?
> > > 
> > > I think the first form above ("foo-contrib | foo") is not acceptable.
> > > My argument is that we should make choice of non-free software an
> > > explicit action of Debian users, rather than an implicit/automated
> > > one.
> > 
> > Would once be fine, or should contrib/non-free users need to make an
> > explicit choice every first time a package outside of Main is an
> > installation candidate?
>  For me, once wouldn't be fine. Just because I might be interested in a
> non-free package for a specific task/documentation/whatever, I am *not*
> interested in general to pull in non-free stuff into my system.  Reason
> is simple:  Every single non-free package has different reasons for
> being there, and while I might be fine with having non-modifyable stuff
> on my system for something specific, when being in a work environment
> non-commercial restriction is a pain, or patent-related restrictions
> should also be explicitly chosen.
>  So *every* time a package outside of main is an installation candidate
> the decision should be made, not once, very much indeed.

As someone who doesn't care about licences I would find it very onerous to 
have to confirm everytime a non-Main package is up for installation, and would 
quickly hack my way around it if necessary.

> > Debian already favours Main packages by default
>  Not if the alternative dependency chain has a non-free package first. I
> know what you mean with that non-free isn't enabled by default, but the
> way the dependency chain is written still favours non-free packages by
> default, when available -- which is the thing you like to emphasis on,
> but the favour is still the other way round.

I disagree. The only way a non-free package is going to be automatically 
selected is if the sysadmin has added non-Main lines to sources.list, and the 
Maintainer has placed a non-Main package before one from Main in the 
dependency statement--that's two explicit actions that need to be taken, 
compared to zero if non-Main stuff isn't wanted.

Why would a Maintainer want to place a non-Main package ahead of one from Main 
in a dependency statement? I can think of two potential reasons: to work 
around a dependency system deficiency; or because the Main alternative really, 
really, sucks. In the first case the solution should be to fix the dependency 
system. In the second there is a choice to be made between providing users 
with the best possible system with the minimum of hoops to jump through to get 
it, or pushing a particular philosophical ideology on them at the expense of 
stability/functionality/etc.--I hope Debian would honour the Social Contract 
and put the needs of the users ahead of software freeness concerns in that 

> > Personally: I'd like to see any philosophical overloading of dependency
> > statements disappear. The statement "A|B|C" should mean that A is the
> > best choice from a technical perspective (stability, functionality,
> > etc.)
>  Not only technical perspective, the DFSG are also very relevant for
> such a decision making.

I don't disagree with that, the two just shouldn't be mashed together because 
any relationship between them is arbitrary. In programming terms, it is a poor 
choice of data structure for the problem. In DB terms, it should be 

>  Please don't forget that the reason for one non-free package might be
> acceptable for a fair amount of users (like debate about GFDL showed)
> while the reason for another non-free package crosses the line for most.
> A general statement of "I installed that one non-free package so I'm
> fine with other non-free packages on my system" is flawed in very many
> senses.

I haven't forgotten, it is where I started, but it quickly became apparent 
that a system for keeping track of preferences on a per-package/suite basis 
would be needed if it was to be done properly. [Since, "Every single non-free 
package has different reasons for being there", it is not reasonable to expect 
that a coarse grained system will satisfy all the potential reasons for 
wanting them.] I believe that it would also require per-reason (non-
commercial, patented, documentation, etc.), and perhaps per-subsystem 
preference tracking and conflict resolution. That seems like it could be a 
huge amount of work so I choose to explore the `fix the tools so that the 
order doesn't matter' and `separate the two functions' options.

Reply to: