Hello Jakub,
you wrote:
ii (somewhat preferable). remove scons from within .orig.tar.gz
I disagree that (ii) is preferable. You should not repack upstream
source unless you have to. (Please see ftp-master's reject FAQ.)
Thanks for the pointer, I looked at it.
(optionally add +dfsg or .dfsg suffix to the version making it
0.3.17~pre2+dfsg-1)
Since the software would be repackaged for reasons that are unrelated to
DFSG compliance, the "dfsg" suffix would be incorrect/confusing.
I have added the removal of "tests/benchmarks" as well, for which I as
an upstream, would accept non-DFSG material as well. There is none of it
in there at this time though.
So yes, Nuitka as upstream is 100% clear to DFSG. Should I change things
back to patches then? These removals may get huge. Imagine e.g. that I
include Shedskin tests or even dare include the whole CPython tests
(once Nuitka is itself PSF too).
Or, probably another way, can I, as an upstream, provide 2 forms of
tarballs, one for packaging and one for everybody else with more stuff
like the scons inline copy and benchmarks and extended tests from 3rd
parties already contained?
I saw the issue being rated as: Minor issues, sometimes also named "Good
packaging behavior". Not a single one is enough to get you a REJECT, but
if you collect multiple ones the probability rises
So, please advise. Like I said, I try to be a "good upstream" :-)
Thanks,
Kay
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f02142e.9040...@gmx.de
