[Pkg-opennebula-devel] DFSG repacking of upstream source - Was: Re: opennebula-4.12.3

[Olivier Berger]

Hi.

Dmitry Smirnov <onlyjob at debian.org> writes:

> On Wednesday 05 August 2015 10:42:45 Olivier Berger wrote:
>> However, I have a doubt.
>> [...]
>> that should be excluded from the .orig. Of course, getting rid of it at
>> the build first stages could help, but no before. Removing from the
>> .orig is only mandated in case of non-freeness.
>
> We drop .JARs because they are pre-built binary files therefore they are not 
> DFSG-compliant. I believe this is necessary because they may have been built 
> using software not present in "main" section of the archive, have incorrect 
> Manifest etc. As far as I'm aware, dropping .JARs from upstream tarball is a 
> usual practice in Debian.
>

I see 2 issues for Debian :
- are these files DFSG-free
- are these files "correct"

The second question is solved by not using them during build/packaging,
since we use instead the files in the Debian archive. Good :-)

However, the first question is more difficult to solve, given that we
don't have the source. However, we can consider that they are genuine
derived versions from free sources, given that they look like well known
Java libraries from the Apache project.

So I would say that we can assume that they are DFSG-free, and we aren't
really required to remove them. It's even less problematic if we don't
use them during the build/packaging time, given that we instead rely on
the variants in the Debian archive (point above).

So it doesnt' harm much of removing them, but on the other hand, it is
convenient to rely on plain upstream release tarballs (for
reproducibility, tracking, etc.), so we might avoid repackaging upstream
sources if we can.

Maybe I've overlooked the policy here, so I'd welcome more pointers on
the subject if you can find some.

>
>> I'm doubtful also about the rest, the "bower_components" stuff. Can you
>> enlighten me (I'll habe a look at the OpenNebula release file to try and
>> have more hints) ?
>
> Sorry, I'm not sure I understand your question. All those files are non-DFSG 
> because they are source-less or minified/pre-built (or both). Try not to drop 
> them and you'll see lintian errors (E:) on some of them (in obvious cases).
> Believe me, I know what I'm doing. :)
>

Same issue as for jars.

Of course, lintian shall complain, but again, if they are derivative
versions of DFSG-free sources, there is no need to get rid and we should
instead try to ship the corresponding sources in d/missing-sources (as I
did for 3.6 recently ;-).

Again, copyright-wise (IANAL), as an example, a binary compiled out of
DFSG-free sources is a derived work which is governed by the same
licences, so hence DFSG-free too. I don't think we have to remove them
from upstream sources, but we only have to make sure that we can and do
recompile them during the package builds.

>
>> That won't be necessary I think, but I'll feel more comfortable adding
>> some details in the README.source about the repackaging of the
>> Files-Excluded directive, so that there are some hints for future
>> (co-)maintainers.
>
> I'm beginning to think that we may have a generation of developers who only 
> know how to build a Debian package using "git-buildpackage". ;)
>

Heh.

Hopefully they are quite some projects still using svn-buildpackage ;)
(but slowly disappearing ;)

> I'm not entirely against importing upstream tarball to "upstream" branch but 
> I just believe it is unnecessary... Maybe you can have a local "upstream" 
> branch? (I'm not sure how to avoid pushing its tags though...)
>

Note that I'm not arguing about upstream sources in Git for GBP,
here. The issue of +dfsg upstream source repacking, is a different
issue.

>
>> I'll try and see how that works with pbuilder, which I don't use by
>> default.
>
> So much troubles to make GBP work...
>

Now, I've tried your GBP settings and got an error, but will deal with
this in a different mail, trying to focus threads on one issue at a
time.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)