When the source provided to dpkg-source contains a .<vcs>ignore file,
eg a .gitignore, .hgignore, .cvsignore, then that file is part of the
source code as the maintainer works with it. It should be retained in
the source package.
Likewise if the Debian maintainer makes changes to .<vcs>ignore in
their vcs, then those changes are part of the source as the maintainer
works with it, and in `3.0 (quilt)' should be represented as a patch.
The result of this default is that many source packages in the Debian
archive are incomplete. This is IMO a DFSG violation (and where
relevant a GPL violation). Although it is probably legally de
minimis, this should be fixed.
Changing this has compatibility implications. Many tools assume the
existing behaviour. I suggest the following transition plan:
* Introduce a new option --new-ignores which causes -I and -i without
further arguments to exclude *only* vcs-maintained metadata (.git,
.hg, CVS etc.) and including all files which are usually committed
to the relevant vcs. Make an environment variable to do the same
thing.
* Start printing a warning when -I or -i is passed on the command
line without a value and without --new-ignores.
* Always treat -I and -i found in debian/source/options the new way.
(there are no compatibility implications in this case).
* In bullseye, always do the new thing and make --new-ignores a
no-op.
But maybe you have a better plan.
This is related to, but distinct from,
#908742 Want way to reset tar-ignore list
which I think ought to be uncontroversial and can be done immediately.
Thanks,
Ian.
[1] Looking at the list in @tar_ignore_default_pattern in stretch, I
think the ones which need to be removed from the list (and thus kept
in source packages) include at least these
.bzrignore
.cvsignore
.gitattributes
.gitignore
.gitmodules
.gitreview
.hgignore
.mtn-ignore
.mailmap
and possibly these
.arch-ids
.arch-inventory
.be
.bzr.backup
.bzr.tags
.deps
.hgsigs
.hgtags
and maybe these (but I think not):
.shelf
_MTN
_darcs
{arch}
Ian.
By the same reason, you could argue that not shipping .git is a DFSG/GPL violation. ignore files are things that integrate the source code with the version control system. Heck, you could even argue that the entire disk of the maintainer is part of the source code with that definition.
Julian Andres Klode writes ("Re: Bug#908747: Default -I and -i option should not exclude .<vcs>ignore"):
it for another day. (If you do subscribe to that argument, I guess
you would always use dgit, or always push your git branch to salsa
with appropriate signed tags.)
Looking more narrowly, it seems to me that: including the .gitignore
(say) is sometimes helpful, and never harmful. So stripping it out is
simply a mistake.
It is helpful, for example, if the user does
apt-get source && cd $p && git init && git add . && git commit
so they can work under version control. This is a common approach to
work around the fact that Debian still often does not publish a
useable branch. Including the .gitignore is helpful for a user
using dgit to fetch a not-uploaded-with-dgit package (because dgit
ends up doing something a bit like that git add.) It is helpful when
handling nmus, sponsorship, etc. because it means the source package
is more like the git repository.
Do you agree ?
Whereas including the .git/ directory is currently forbidden in
Debian. That is surely a separate, much wider, debate, which I would
be happy to have with you - indeed, I am sympathetic - but not in this
bug report.
Ian.
Ian Jackson writes ("Default -I and -i option should not exclude .<vcs>ignore"):
Ping?
In particular, (i) do you agree that this should be changed
and if so (ii) what did you think of my transition plan ?
At least this part:
Could safely and usefully be done in buster even at this stage.
Thanks for your attention.
Ian.
I didn't implement this feature, so I could be wrong, but my understanding
is that the rationale for making it convenient to ignore .gitignore,
.bzrignore and friends is:
- Some maintainers don't have upstream source in their VCS at all (more
or less ubiquitous before wide adoption of git, and still sometimes done
even with git), so they want to unpack the upstream source into their
packaging-only git repository and create a ./.gitignore to ignore it
for git purposes. If that was included in the source package, it would
enlarge the diff (1.0 format) or require creation of a new patch in
the patch series (2.0 or 3.0 (quilt) format).
- Some maintainers do have upstream source, but it's an import of the
orig tarball created by Autotools `make dist` or equivalent, which
very rarely includes .gitignore even if upstream originally had one;
so they want to create ./.gitignore (possibly a copy of the one from
upstream's VCS) to ignore build products. If that was included in the
source package, (see above).
(I personally agree that .gitignore and other .git?* files ought to be
considered part of a source package, particularly debian/.gitignore,
and accordingly I have debuild configured to use -I.git rather than -I;
but my opinion is not the only valid one.)
smcv
Simon McVittie writes ("Re: Bug#908747: Default -I and -i option should not exclude .<vcs>ignore"):
I think in fact that it was not so considered a decision, but that
doesn't matter because we should consider counterarguments on their
merits. So...
done a survey.)
But there is a serious problem with this argument. In this scenario,
the maintainer *is using the .gitignore as part of the source code*.
They use it to ignore build products. Someone who imports the dsc
into git (there are various tools that do this - not just dgit) wants
that .gitignore too, for the same reason.
It is true that in this scenario (with `3.0 (quilt)') the maintainer
would need to make a patch to include .gitignore.
But this hypothetical maintainer's argument is, ISTM, simply: "It is
slightly inconvenient to supply the proper source code because I have
to manage this bit of source code in a way that publishes it
properly." When I look at it like that it seems obviously very wrong.
The fact that this bit of source code is of relatively minor
usefulness (and used to be of even more minor usefuless) does not
really address this serious problem of principle.
Now I think it is unarguably true (in your example scenario) that the
.gitignore is part of the source code, if we take "source code" to
mean "the preferred form for modification" (as the GPL does and as we
usually do in Debian).
But even if you don't take that view, it is certainly true that the
.gitignore is useful for some users and that the inconvenience of
shipping it as a patch is very small. This does not seem like a
proper tradeoff to me.
to dispose of. I confess it hadn't previously occurred to me that
people might try to use .gitignore for this.
In this situation the .gitignore would presumably contain *all* the
upstream source. Ie it would say
**
!debian/**
or something equivalent.
In a .dsc that would not be useful; indeed, it would be harmful -
because anyone who receives such a .gitignore via the .dsc, and
subsequently experiences its effects, will be someone who has imported
the .dsc into git, upstream files and all. They will not want all the
upstream files ignored !
But: it doesn't seem to me that this scenario could have been the
motivation for the default ignore set in dpkg-source, because the
default ignore set applies to all source formats equally, and it is
only `3.0 (quilt)' for which this could possibly make any sense.
I have no idea what proportion of packaging-only repositories have a
root .gitignore at all, let alone one like this. I suspect it is very
rare, so this argumnt is theoretical. And someone with this workflow
has other options.
I hope this makes sense.
Thanks,
Ian.
ping? Once again I have a user who tripped over this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998394
I agree with Ian. If package maintainer wants to have a few extra ignore rules locally, why not use file. I think its high time to fix this. Osamu
I also agree with Ian. If the Debian maintainer put a file in the debian/ directory, that file should be included in the sources by default. The current default behaviour leads to costly auditing of differences between *.debian.tar.* and git packaging content. It is hard to tell if any of the ignored files can be turned into a xz-style payload vector. /Simon