On September 22, 2011 02:50:25 AM Gerfried Fuchs wrote:
> * Bruce Sass <bms...@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
case.
> > 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
normalized.
> 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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201109220819.33075.bms...@shaw.ca
