[Debian-med-packaging] liblemon_1.3.1+dfsg-1_amd64.changes REJECTED [and 2 more messages]

Andreas Tille tille at debian.org
Tue Aug 9 15:31:47 UTC 2016


Hi Ian,

On Tue, Aug 09, 2016 at 03:33:16PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: liblemon_1.3.1+dfsg-1_amd64.changes REJECTED [and 2 more messages]"):
> > On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote:
> > > Are you really saying that it is not necessary for the .deb to contain
> > > the authorship and copyright notices for the contents of the package ?
> > 
> > I do not think that this was said.
> 
> Perhaps I am confused; there have been a number of positions advanced
> by various people.  Sorry if I have misrepresented anyone.

I'm pretty convinced that I'm confused myself the more I read about this
issue.

> > > ISTM that if the .deb contains this jquery.js, then the .deb (or
> > > something it Depends on) must contain the authorship and copyright
> > > notices for that jquery.js.  (This is both an ethical and legal
> > > requirement.)
> > 
> > Sure.  But this is documented in the Build-Depends of the package,
> > isn't it?
> 
> I don't understand how this response makes sense.  Perhaps I am
> ignorant of the facts.
> 
> In an effort to better understand what was going on, I tried to find a
> copy of the package which was rejected, or of the REJECTED notice.  I
> wasn't successful.  Perhaps I looked in the wrong places.

Its on the debian-med-packaging list[1].
 
> My understanding of the facts is:
> 
> 1. The source package declares Build-Depends on doxygen.  During
>    the build, doxygen is run to build the documentation.

Yes.
 
> 2. During this docs build doxygen copies this jquery.js into the
>    resulting .debs.

Yes.

> 3. Confusingly this jquery.js is not actually JQuery.

This is what I learned in this thread.  I'd call this *very* confusing
and it might have been discussed before but IMHO that's a bug and this
file should be rather called doxygen-jquery.js (or something better).

> 4. Nothing puts anything (relevantly) in Built-Using.

Yes - at least not manually in the debian/ dir[1]
 
> 5. The source package contains a copyright file which does not mention
>    doxygen or contain any information about this jquery.js.

Yes.

> 6. The copyright file from the source package is copied automatically
>    into the .debs and nothing modifies it.

Yes.

> 7. Consequently, the .debs do not contain the authorship or copyright
>    notices relating to this jquery.js, even though they contain the
>    file.  (Nor do they contain references to the notices.)

Yes.

> IMO:
> 
> 1 (running doxygen to build the docs) is obviously desirable.

Yes.

> 2-4 (copied rather than referenced jquery.js; anomalous name for
> jqeury.js; lack of Built-Using) are all undesirable, but none of them
> are RC bugs or REJECT-worthy.

Agreed.

> 5 (source copyright file does not mention any of this) is correct,

Yes.

> although it would not be wrong to mention it.

I keep on failing to understand why I should mention a file that results
from any build process.  I'm not sure if this is an analogous question
but why should I for instance mention the copyright of some PDFs created
in the documentation build process.

> 6 (nothing inserts relevant info into .deb copyright files) is a
> missing critical feature (probably, in dh_doxygen).

Please call me ignorant but why is this critical?
 
> 7 (lack of authorship and copright info in .deb for a file contained
> in the .deb) is a release-critical bug and a proper reason for the
> package to be REJECTED.

We usually have *lots* of files (all results of a build process) which
do not have any explicite copyright info inside the .deb.  In how far
is this jquery.js different than any other build result.

> In the absence of improvements to the tools, the problem could be
> worked around by each doxygen-using package putting "unused" copyright
> information, about jquery.js, in the source package copyright file.
> But this is annoying to do because lintian complains, and because this
> copyright info would easily get out of date and need updating.

On one hand this is annoying for the said reason.  On the other hand I
fail to see a criterion under what circumstances I should add an extra
copyright notice.

> > > IMO this doesn't depend on whether this jquery.js results in a
> > > Built-Using.
> > 
> > I'm not aware that we document in d/control any files that are not
> > contained inside the package source.  If the package builds inside a
> > pbuilder chroot it can be perfectly assumed that all content is
> > documented properly in the Build-Depends.
> 
> I think that part of the misunderstanding is a confusion between
> source copyright files and binary copyright files.

I agree that my statement might lead to the conclusion that this was
confused.  However, my arguing is that the copyright of jquery.js is
mentioned "somewhere else" (I agree that this is not really transparent
for the user) but the binary package contains *lots* of other JS files
/usr/share/doc/lemon/html/search/all_*.js which are auto-generated as
well.  So what exactly is the rule to document any file in a binary
package?

Kind regards

       Andreas.

PS: I admit I fail to see the real advantage for the user to have the
copyright of auto-generated files in binary packages mentioned and I
consider my time not very well spent in this respect.  Users can assume
that everything in main is free and copying and using this autogenerated
file makes no sense anyway.  So what exactly are we discussing here?

[1] https://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-August/045093.html
[2] https://anonscm.debian.org/git/debian-med/liblemon.git

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list