-----BEGIN PGP SIGNED MESSAGE----- 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? Thanks, Bas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWmlsEAAoJEJzRfVgHwHE6vH8QAJ1PDeJ6/R5Yoh0S661eDlvP TwqwLQqABMRnnUKi1+MYHNTUfxT13hbfSVcymEvlQJ9xQvYAE8H6DUKr43eyzOmJ d0UBNOc9HI/5rx9A2nyY9Pz7u09StLzy1btD1rZUa9LaCzZm2WAj0HtWSpsH27yq tOAB9nObLj01ZOANotP6VpIX2lUm2G85ROGgivv4pkhDVEAzgzPX1mRTOrYX/y2E FPtdcdanWrqKgQuIgxhQAkzcOk4ylnU4DOqdSlHgwWlaQ/KJVG95awqI1D83DqbZ EyKsezbD6rV6k9+FuGgb6xou6/xPxNM8e0ogZwWSOiuz0GdV9ap5P1tTUtO71iqu jsDndRFFoOKhbGuCHYAqYLEToOxKbgGlc8nKm7b2GzxqefJVkcoP8UdZZFNNqEr3 Y0lNFbSYdwjMGalMbsEt2hpizUQDOZLi6FMC42TRGlqLycPg9fg5GTR4dzdamtj+ ZfYjLu/zw+562fWJqyJZLFEBkIyZIIuAhXcQwLZSh9+1OYfeLwgmZgIx2bjvkKkL zohrbHLtc3ozQAV1SKCMUSRkzAQQguq2MxGu7+8D4EYShj8uNGA2hoZbTu6iPKLM XE1Ef+ceg+j9ji9DifRILV6TaIGv2thl1TqAijjTBAgGSWQhv3srejchvCHYwxe0 jxMPCZfwt+Et43WEx8OV =8mga -----END PGP SIGNATURE-----
