Bug#621462: marked as done (base-files: missing AGPL-3 license)

2011-09-20 Thread Debian Bug Tracking System
Your message dated Tue, 20 Sep 2011 15:30:43 -0700 with message-id <87obyezw18@windlord.stanford.edu> and subject line Re: Bug#608324: please add Affero license to /usr/share/common-licenses has caused the Debian Bug report #621462, regarding base-files: missing AGPL-3 license to be marked as

Bug#608324: marked as done (please add Affero license to /usr/share/common-licenses)

2011-09-20 Thread Debian Bug Tracking System
Your message dated Tue, 20 Sep 2011 15:30:43 -0700 with message-id <87obyezw18@windlord.stanford.edu> and subject line Re: Bug#608324: please add Affero license to /usr/share/common-licenses has caused the Debian Bug report #621462, regarding please add Affero license to /usr/share/common-lice

Re: packages under the AGPL-3 license

2011-09-20 Thread Russ Allbery
Benjamin Drung writes: > Am Dienstag, den 20.09.2011, 14:25 -0700 schrieb Russ Allbery: >> I personally consider 1000 packages to be the appropriate level for >> considering including something new in common-licenses, but I'm fairly >> conservative on that front. The closest (by far) of the lice

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

2011-09-20 Thread Paul Wise
On Tue, Sep 20, 2011 at 8:04 PM, Ben Armstrong wrote: > While that neatly sidesteps the issue, 7.5 says: > >     To specify which of a set of real packages should be the default to >     satisfy a particular dependency on a virtual package, list the real >     package as an alternative before the

Re: packages under the AGPL-3 license

2011-09-20 Thread Benjamin Drung
Am Dienstag, den 20.09.2011, 14:25 -0700 schrieb Russ Allbery: > I personally consider 1000 packages to be the appropriate level for > considering including something new in common-licenses, but I'm fairly > conservative on that front. The closest (by far) of the licenses not > already listed ther

Re: packages under the AGPL-3 license

2011-09-20 Thread Russ Allbery
Stefano Zacchiroli writes: > On Wed, Sep 21, 2011 at 01:28:26AM +0530, Ritesh Raj Sarraf wrote: >> I am working on packaging the LIO tools [1]. The userspace component is >> licensed under AGPL-3. >> As per Debian bug #621462, the license is not part of common-licenses >> because there aren't ma

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

2011-09-20 Thread Jonas Smedegaard
On 11-09-20 at 07:41pm, Luk Claes wrote: > On 09/20/2011 01:12 PM, Gerfried Fuchs wrote: > > Hi! > > Hi > > > Policy is clear on packages in main aren't allowed to depend on > > packages outside of main. Now in a fair amount of cases this has > > been worked around by having the packa

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

2011-09-20 Thread Luk Claes
On 09/20/2011 01:12 PM, Gerfried Fuchs wrote: > Hi! Hi > Policy is clear on packages in main aren't allowed to depend on > packages outside of main. Now in a fair amount of cases this has been > worked around by having the package outside of main as alternative > dependency and a packag

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

2011-09-20 Thread Ben Armstrong
On 09/20/2011 08:43 AM, Paul Wise wrote: > On Tue, Sep 20, 2011 at 7:12 PM, Gerfried Fuchs wrote: > Package: bar > Depends: foo > > Package: foo-contrib > Provides: foo While that neatly sidesteps the issue, 7.5 says: To specify which of a set of real packages should be the default to

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

2011-09-20 Thread Paul Wise
On Tue, Sep 20, 2011 at 7:12 PM, 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 vote: Package: bar Depends: foo Package: foo-contrib Provides: foo -- bye, pabs h

alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Gerfried Fuchs
Hi! Policy is clear on packages in main aren't allowed to depend on packages outside of main. Now in a fair amount of cases this has been worked around by having the package outside of main as alternative dependency and a package in main offer basic functionality for the package to still