On Mon, 28 Aug 2023 13:53:22 +0100 Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
Package: dgit
Version: 11.3
debhelper (at least in sid) has a debian/source/options with;
tar-ignore
tar-ignore=debhelper/.idea
And it has a .gitignore. This has the following effects:
1. It defeats dgit's passing of a -I and -i options to dpkg-source,
so the dgit-generated source package does not contain .gitignore
2. If one were to somehow manage to make a proper source package
that corresponds to the git tree, it wouldn't round trip
through dpkg-source.
So IMO there is no way to make a DFSG-compliant source package of
Debian's current debhelper package.
I was just assisting another DD contributor with this and other
problems; I was going to try to help sort out a mess by doing what
amounted to a sponsored upload. However, this turned out to be
impossible.
I have done a non-dgit-based non-DFSG-compliant upload instead.
What should we do about this ? Options (not mutually exclusive) could
include:
* File a bug or MR against debhelper
* Somehow ask that dpkg-source do something about this, but what ?
* Have dgit detect this situation and at least explain it to the user
* Have dgit generate a non-roundtrippable source package
(probably very hard and also undesirable)
Ian.
[...]
Hi,
So this is a common pattern in my packages although it sometimes appears
in d/s/local-options rather than d/s/options.
Basically, the issue is when you have something you want to have
locally, not in git and also not in the archive. In one my other
packages, I have a "local" directory filled with local work items
(including a full copy of the sudo deb package for testing purposes).
Here the "local" directory is listed both in .gitignore and in
"tar-ignore", because I do not want it in git nor in the archive when I
do an upload.
To solve this, I add `tar-ignore=...` (for native packages) to
debian/source/(local-)options. However, if you add that option, you end
up with the entire *.git* directory in the tarball. To avoid that, I
add the `tar-ignore` on its own to get the sane defaults back.
This then breaks dgit leading to this bug, which is kind of a catch-22
if you want local specific things (IDE files or local prototype stuff)
that you guarantee is excluded from git and dpkg-source automatically
and also support dgit at the same time.
Best regards,
Niels
PS: Not sure if this problem is specific to native packages, which I
happen to maintain a lot of (relative to other maintainers).
PPS: Another example is debputy/experimental. In there I also included
some python related artefacts because the early drafts do not have a
proper clean rule for all the "local only" tooling I use, such as python
coverage. The official builds do not use these things, so the clean
rule should work fine, but I do not want a left over ".coverage"
appearing in the source package as it is just cruft.
