On Thu, 12 Sep 2013, Ian Jackson wrote: > I'm not sure where you're going with this. These dpkg-source ignores > are things which are ignored by dpkg-source when constructing the > source package. So they shouldn't be in the git tree either. If they > are there, then the git tree is not suitable. If they are generated > files, then they should be removed by debian/rules clean and would > therefore not end up in the source package even if they were not > ignored.
I'm afraid that none of those premises hold true. I have used the ignore options (via debian/source/options) precisely to avoid having to clean them in debian/rules because removing files which are in the upstream tarball but are regenerated/modified during build is problematic. I have also added .gitignore files listing such files in the debian packaging repository that I use while the upstream tarball (or upstream git repository) doesn't contain any such file. And it would be a mistake for dgit to introduce that file in the Debian source package under the form of a new quilt patch... So maybe you believe that my git tree is not suitable for use with dgit but I would rather claim that dgit copes badly with a legitimate usage of either packaging options that the maintainers have or of VCS-specific files that one should be allowed to use without interferring with the generated source package. > > This just means that when you detect a difference you should fallback > > to do exactly the same as you do when you import a source package from the > > archive, no? > > When we detect a difference during dgit build, you mean ? No, because > dgit build, and push, is an output operation. You're supposed to > already have a git commit containing the correct tree. That supposition is fragile IMO. You rely on some assumptions about dpkg-source and the various source formats which are not guaranteed to hold true indefinitely... and which in some cases already do not hold true. Try "debcheckout krb5-sync" and see how debian/source/local-options and debian/source/local-patch-header do not end up in the generated source package. > > And what is supposed to happen when you want to mixin the upstream git > > repository which has for example a directory that is excluded from the > > generated tarball that is used in the debian package? > > You need to represent that change (the removal of the directory) in > git. This is something that I would rather avoid because merge will always generate conflicts as soon as something has been modified in this directory. It is much easier to just ignore that directory instead of removing it. > The principle behind dgit is that you don't have to worry about any of > this. The git tree provided and used by dgit is exactly correct. While this might be ok if you start with "dgit clone", many existing packages do already have a git repository. And when you "dgit pull" in such a repository, your git tree will be "tainted" by whatever the maintainer might have done to it. > If you are the maintainer and want to use dgit, you can use whatever > gitish technique you like to construct a tree which is suitable. > dpkg-source ignore options are not a gitish technique, do not affect > the git tree, and therefore are not suitable. So if you are the > maintainer and want to use dgit you should probably not set any > dpkg-source ignore options. This is an arbitrary restriction that doesn't fly well with me, and by experience, if you want dgit to become mainstream, you should adopt a more "inclusive" approach. The nice thing about dgit is that it offers a gateway between git and direct work in a source package, but if that gateway adds arbitrary restrictions, then it becomes less useful. > I think the current behaviour serves those users well. Your implied > proposed change would serve those users less well. How so? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
