Re: Let’ s turn DEP5 into something useful

2009-06-15 Thread Don Armstrong
On Sat, 13 Jun 2009, Mike Hommey wrote: > On Sat, Jun 13, 2009 at 10:06:31AM +0100, Neil Williams wrote: > > Requiring any details of precisely which files are affected makes the > > whole thing impossible because that requires some form of mass-update > > (or at least mass check of individual fil

Re: Let’ s turn DEP5 into something useful

2009-06-14 Thread Charles Plessy
> Nowhere does it make any mention of source filenames. > > Now please drop that shit from your proposal, and maybe we can discuss > it sanely without counting commas. I am all for making all the fields optional. This is a major change from Sam‘s original proposal. The reason it has not been don

Re: Let’ s turn DEP5 into something useful

2009-06-13 Thread Steve Langasek
On Sat, Jun 13, 2009 at 03:28:50PM +0200, Andreas Rottmann wrote: > A real-life example from libunistring (which I've filed an ITP for [1]): > The source files that will constitute the resulting library package are > all LGPL-3+'d, but the source tarball also contains a test suite, which > is GPL-3

Re: Let’ s turn DEP5 into something useful

2009-06-13 Thread Charles Plessy
Le Sat, Jun 13, 2009 at 10:52:36AM +0200, Josselin Mouette a écrit : > > So, how about dropping entirely anything that’s related to files and > only keep the amount of information we are requiring now? I feel sorry > for the giant bikeshedding thread about spaces and commas, but it is not > getti

Re: Let’ s turn DEP5 into something useful

2009-06-13 Thread Bart Martens
On Sat, Jun 13, 2009 at 10:52:36AM +0200, Josselin Mouette wrote: > Hi, > > currently, DEP5 is not, contrary to what the name says, about a > “machine-readable debian/copyright”. It is about providing a much > broader amount of licensing information on our source packages. > > The real problem wi

Re: Let’ s turn DEP5 into something useful

2009-06-13 Thread Mike Hommey
On Sat, Jun 13, 2009 at 10:06:31AM +0100, Neil Williams wrote: > Requiring any details of precisely which files are affected makes the > whole thing impossible because that requires some form of mass-update > (or at least mass check of individual files) at every upstream release. > Let's just drop