Normally the debian stuff has to fill in whatever gaps are not handled
well by the upstream makefiles. Often this includes cleaning up or
moving files around. You have the luxury of being in control of upstream
which means you can interpret "upstream" how you want. You choose to
interpret upstream maximally but you could have chosen to interpret it
minimally.
However I am NOT trying to persuade you to change. I just wanted to
understand.
I have moved the clean up into the One time functions.
The emails I referred to were:
https://lists.alioth.debian.org/pipermail/devscripts-devel/2015-December/004370.html
https://lists.alioth.debian.org/pipermail/devscripts-devel/2015-November/004259.html
I am not really expecting an answer for either this side of the upload.
On 05/12/15 17:27, James McCoy wrote:
On Sat, Dec 05, 2015 at 02:12:38PM +0000, Nicholas Bamber wrote:
James,
I can move it back of course.
I am actually puzzled why more is not done in debian/rules.
Like most packages, debian/ should only contain content that's relevant
for packaging.
Properly cleaning up detritus created by a test isn't specific to
packaging, so it should be handled by the test (e.g., using shunit's
oneTimeTearDown) or possibly by a clean target in test/Makefile.
The whole
devscripts structure seems sort of odd to me.
Why? Debian-specific stuff should be handled by things in debian/.
"Upstream" stuff should be handled outside of debian/.
I put the test clean up in debian/rules because then one can easily
inspect
the generated files between the test phase and the clean phase. More
generally I can think of several places such clean up could be put in:
1. debian/rules
2. Makefile
3. test/Makefile
4. test/test_*
The two obvious places would seem to me 1. and 4. 4. seems not to be
working.
Looking at test_package_lifecycle, it seems like use of either
oneTimeSetUp/oneTimeTearDown or setUp/tearDown would help.
I am not quite sure why though I suspect the test script may be
exiting earlier than the cleanup. However 1. looks better to me anyway for
the reason I said. Both 2. and 3. look wrong to me. Why should test/Makefile
know about the inner workings of the tests?
Why shouldn't it? Do you expect other upstream Makefiles not to know
how to clean up their generated files? The use of “debian/rules clean”
should typically only need to clean up files generated by the packaging,
not by the upstream build process. The upstream files should be cleaned
by the upstream code.
BTW there are several quetsions I have asked which have not been answered.
If they're buried in email chains about commits, where I wasn't already
part of the thread, that's probably why. Start new threads when you're
discussing new topics.
Also what are the plans for upload?
In the next week or so, probably.
Cheers,
_______________________________________________
devscripts-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
