On 30/10/15 15:29, Alec Leamas wrote:
On 30/10/15 12:45, Ghislain Vaillant wrote:
Just my 2 cents here but quoting d-mentors FAQ [1]:
"There are cases where upstream ships a tarball which already contains a
debian directory. This is undesirable, even if you're upstream yourself
or can commit there. Keep the released tarballs (used as .orig.tar.gz)
and the debian directory separated."
hm... from the same reference:
There's no need to remove the debian directory from their revision
control system (although if it's out of date they may decide to do so
anyway), but at the very least the directory shouldn't appear in
releases.
If you are upstream yourself, well, you can ask yourself to do it.
We don't plan to ship the debian subdir in the package tarball, but as a
separate set of files (debian,.tar.gz, lirc_0.9.4.orig.tar.gz, *.dsc,
*.build).
All of which can be generated with dpkg-buildpackage on a separate
branch containing the source tree + packaging.
Isn't this according to this what's actually suggested in that
FAQ? Or did I miss something?
All the FAQ is saying is that the source tarball should be ideally free
from any packaging metadata.
Having the debian/ folder included in master is not a step in the right
direction, because *either* upstream (you) has to commit to distribute a
separate tarball (different from the corresponding tag on master)
stripped off all the Debian metadata *or* downstream (us) has to
implement a repacking step.
The bottom line is that each case results in additional work for one
party, for little benefit overall.
Instead, keep the packaging in a different branch (as we do) and get
familiar with our tools (git-buildpackage) to generate the source and
binary packages. Chances are you will have to do it for testing your
work anyway. I am happy to help you getting started with the setup if
required.
That said, I completely agree it would be better if someone (preferebly
with debian packaging skills) maintained an actual package.
What matters is getting the packaging metadata updated with the latest
upstream release of your software. Whoever "maintains" this work in the
long run is of little relevance right now.
It's just that it seems unlikey to happen unless upstream does something (?)
And I think it is great that you decided to take the matter in your
hands. You also made yourself clear that you have little faith in the
current maintainers at the moment, but we have yet to hear of any
confirmation from them.
Ghis
