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

Defaults and virtual package rules (was: default softphone in Debian stretch)

Hash: SHA1

On Sat, Jan 16, 2016 at 01:48:46PM +0100, Daniel Pocock wrote:
> On 15/01/16 14:20, Bas Wijnen wrote:
> > On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
> >> On 15/01/16 04:00, Paul Wise wrote:
> >>> On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote:
> >>> 
> >>>> default softphone in Debian[1]
> >>> 
> >>> It should be up to the user what communications tools they want
> >>> to use and or have installed (if any), that is none of our
> >>> business, other than perhaps informing them of the security
> >>> properties of what is available and or providing the default
> >>> upstream tool choices via metapackages where available.
> > 
> > I strongly disagree.  Users should be able to choose, and we should
> > not force one option on them.  But users should not be forced to
> > choose.  A major feature of using a distribution is that you don't
> > need to choose individual programs to install, but get a well
> > functioning system.
> > 
> > Don't confuse the freedom to choose with the obligation to choose.
> > Freedom is good, and so is having good defaults.
> Yes, I wasn't insisting that every user should be forced to install
> something or even worse, forcing users to create a SIP or XMPP account
> in some designated service provider.

I wasn't disagreeing with you, but with Paul.  AIUI, he wants to force users to
choose which softphone they want.  I understand the resistance against forcing
users to install one softphone and not allowing them to use any other.  But
that doesn't mean there shouldn't be a default.  If a user wants a softphone
and doesn't care which, they should be getting a good default.

In short, if a user wants a softphone, Paul says: we give the options and they
_must_ study those options and choose one.  I say: we give them one that works
well, plus a list of options.  They can ignore the list of options if they
don't care about it, or use it to get exactly what they want if they do care.

> Making it as easy as possible for those who do want such things and
> helping them make a good choice on their first attempt are the things
> I'm concerned with.

I almost agree.  On their first attempt, I don't want to help them make a good
choice; I want to make the choice for them.  Unless they want to choose
themselves, of course; I'm not saying we should stop that.  But I think most
people just want it to work.  They don't care what the program is called, and
they don't want to spend their time on choosing one.

> >> I think there should be a threshold.  Failing to meet that should
> >> be ground for an RC bug.  In other words, the package can be in
> >> unstable, but not in testing (or stable).
> >
> > Is this approach used in a formal manner with any other sets of
> > packages, meta-packages or tags in Debian?
> No, I don't think we have some sort of "quality" level for providing a
> virtual package.  Just take a look at www-browser which is provided by
> packages not getting any security updates at all or implementing SSL in
> very broken ways (I remember reading about browsers that would just
> accept any certificate silently).

Perhaps it would be good to allow virtual packages to have a description where
they can specify rules that providers must follow in order to be allowed to
provide it.  And in some cases, it may be possible to run automated tests (if
one of the rules is to implement some protocol).  This could be implemented by
creating a package that is used as a Build-Depends, which adds the virtual
package to the Depends of selected packages through substvars.  Lintian can
check that packages don't have hardcoded Depends on the virtual packages.

Would this be useful for more virtual packages, or not?

Version: GnuPG v1


Reply to: