Re: Bug#688251: #688251: Built-Using description too aggressive

2013-10-13 Thread Charles Plessy
Le Sun, Oct 06, 2013 at 05:30:12PM +0900, Charles Plessy a écrit : The attached patch is a third attempt, which underlines that the Built-Using field is particularly useful when a given package, contributing contents included in another package, can not be replaced by a later version. It

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-10-06 Thread Charles Plessy
Thanks everybody for your contributions to clarify the uses case of the Built-Using field. The attached patch is a third attempt, which underlines that the Built-Using field is particularly useful when a given package, contributing contents included in another package, can not be replaced by a

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-10-01 Thread Steve Langasek
On Sat, Sep 28, 2013 at 03:01:51PM +0200, Stefano Zacchiroli wrote: On Mon, Sep 23, 2013 at 09:08:55AM -0700, Russ Allbery wrote: The question is how to make it clear that's not the intent, which requires figuring out how to separate the other use cases from the gcc and glibc case. I

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-28 Thread Charles Plessy
user debian-pol...@packages.debian.org tag 688251 - patch usertags 688251 discussion thanks Le Mon, Sep 23, 2013 at 09:08:55AM -0700, Russ Allbery a écrit : The basic problem that we're trying to solve is that nearly every package in Debian incorporates code from gcc and/or libc into the

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-28 Thread Stefano Zacchiroli
On Mon, Sep 23, 2013 at 09:08:55AM -0700, Russ Allbery wrote: The question is how to make it clear that's not the intent, which requires figuring out how to separate the other use cases from the gcc and glibc case. I guess the general answer you're looking for depends on the use cases

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Paul Wise
On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote: do you think that the attached patch would solve the problem ? There are more reasons for using Built-Using than licenses, for example: Rebuilding against updated versions of static libraries. Rebuilding the debian-installer-*-netboot-*

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Charles Plessy
Le Mon, Sep 23, 2013 at 10:56:28AM +0200, Paul Wise a écrit : On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote: do you think that the attached patch would solve the problem ? There are more reasons for using Built-Using than licenses, for example: Rebuilding against updated

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Paul Wise
On Mon, Sep 23, 2013 at 11:04 AM, Charles Plessy wrote: I paste below the current wording in the Policy 3.9.4. If you have an improvement to propose, that would be much appreciated ! The wording doesn't appear confusing to me so I'm not the best person to propose wording changes. The

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Ansgar Burchardt
On 09/23/2013 10:56, Paul Wise wrote: On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote: do you think that the attached patch would solve the problem ? There are more reasons for using Built-Using than licenses, for example: Rebuilding against updated versions of static libraries.

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Russ Allbery
Paul Wise p...@debian.org writes: On Mon, Sep 23, 2013 at 11:04 AM, Charles Plessy wrote: I paste below the current wording in the Policy 3.9.4. If you have an improvement to propose, that would be much appreciated ! The wording doesn't appear confusing to me so I'm not the best person to

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-22 Thread Charles Plessy
tag 688251 patch thanks Le Thu, Sep 12, 2013 at 08:57:34AM +0900, Charles Plessy a écrit : I would like to make the short-term clarification for the next revision of the Policy. In its simplest form, it could be the addition of something like when the combination of licenses requires to