[Debian-olpc-devel] Sponsorship / review request (multiple activities)

Jonas Smedegaard dr at jones.dk
Wed Aug 4 14:24:45 UTC 2010

On Tue, Aug 03, 2010 at 11:25:48PM +0530, Ankur Khurana wrote:
>> In debian/copyright I prefer to always put license sections at the bottom.
>>  This is in my interpretation mandatory when reusing a License, but 
>> even when only used once I find nicer to be able to skim through 
>> files sections separately from License sections.  I tend to sort the 
>> License sections with the most popular (in that specific package) 
>> license first (i.e. at the top of the bottom, if you know what I 
>> mean).
>But is there any order we should specifically use to order license 
>section.I did the same thing you said here but for the order you 
>mentioned.I picked them in the order they appeared in my copyright 
>file.So any hints here?

Separating License sections from Files sections affects what you express 
(i.e. first listing "these files licensed as foo which means bla bla" 
and later listing "those other files licensed as foo" does not clearly 
identify the second foo as being the same as the first.

Order of Files sections also affect what you express (later wildcard 
expression may shadow earlier explicit one).

Order of Licenses sections, however, does not (as long as they all are 
listed below all Files sections) affect what you express.  My suggestion 
to order by amount of use in the project rather than in order of 
appearance is simply because I believe that to be the ideal order for 
users to read it.

Not sure if above covers what you asked.  If not, please do try again

>> Copyright holders need not be comma-separated - so I suggest 
>> stripping the few stray trailing commas.
>but between year and copyright holder we add comma , just confirming 

Yeah.  I prefer to consistently separate year and copyright holder with 
a comma.  Not crucial, just find it more natural to read that way.

Also, as you probably noticed I consistently squash multiple contiguous 
years together with a dash (instead of explicitly listing each year as 
in e.g. Makefile.in files), and separate multiple non-contiguous (groups 
of) years by comma.  I used to not make a space after such repetition 
commas but have later changed my mind: I actually do not know if similar 
in english grammar, but in danish (my mother tongue) there is *always* 
space after comma (except as floating point in numbers).

>> There should be no need to remove COPYING files from binary packages: 
>> the CDBS snippet python-sugar.mk replaces those with a symlink if 
>> truly fully identical to the Debian-shipped file.
>I was confused here , are you referring to lintian warnings that we 
>tried to remove by adding in install rule? or i am mistaken?

No, I am referring to adding a build rule to explicitly remove COPYING 
files.  Concretely I stumbled across the following in packaging git of 
the Physics activity:

	rm -f debian/sugar-physics-activity/usr/share/sugar/activities/Physics.activity/COPYING

I believe (but did not test) that above is superfluous, as CDBS snippet 
python-sugar.mk already contains the following:

# Replace superfluous COPYING files with symlinks
$(patsubst %,binary-post-install/%,$(DEB_PYTHON_SUGAR_PACKAGES)) :: 
	! test -f $(DEB_DESTDIR)/usr/share/sugar/activities/*.activity/COPYING \
	|| ! diff -q /usr/share/common-licenses/GPL-2 $(DEB_DESTDIR)/usr/share/sugar/activities/*.activity/COPYING \
	|| ln -sfT ../../../common-licenses/GPL-2 $(DEB_DESTDIR)/usr/share/sugar/activities/*.activity/COPYING

If lintian warns about superfluous licenses files, it might be right, 
and we'd better discuss here before silencing them.

Kind regards,

  - Jonas

  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20100804/5e64e85e/attachment.pgp>

More information about the Debian-olpc-devel mailing list