On 2016-08-10 11:52, James Cowgill wrote: >> Actually we should repack ( to get rid of upstream .gitignore file and >> > use our .gitignore file ) and rename. > You don't actually need to do that (and arguably you should not repack > orig tarballs unless you need to). For source format "3.0 (quilt)", > dpkg-source contains a set of regexes for files which are automatically > ignored when generating the final source package. .gitignore (and .git/) > are on the list so any changes you make to upstream's .gitignore are > completely ignored by dpkg-source.
i was wanting to ask about best practices regarding .gitignore for some time. when packaging, i have two "problems" with .gitignore #1 upstream includes a .gitignore having an upstream .gitignore field usually just creates trouble as it (mostly) hides stray artefacts lying around until dpkg-source comes and complains. i really think that gitignore's main purpose is exactly this hiding of build artefacts, but it mainly causes trouble when it comes to Debian's build chain. with my Debian hat on, i would like to get rid of all upstream .gitignore files, ideally *automatically* (to catch all those gitignores in subdirectories...) with my upstream hat on, i desparately need .gitignore though... a "solution" which i often find applied (by myself, and others like mira) is to just strip away the .gitignore file, when repacking the sources (though afaik this is only done when the sources are repackaged anyhow) #2 ignoring Debian toolchain artefacts most packages use "3.0 quilt", which I (unlike many others) have no problems with. unfortunately, using quilt results in a .pc/ directory in the project root, something that gbp will loudly complain about. the most common "solution" is to add .pc/ to .gitignore now my problem is, that i heartily dislike both of these solutions. the two reasons if found for my dislike are: - they modify files outside of debian/, which i think is a no-go (where does it end?), or at least ugly as hell. - they add cruft to each and every package to solve a common problem. i have (very unsystematically) tried to solve this problem in a more central manner over the last few years, the idea being that this can either be solved in the toolchain involved (gbp) and/or via some local configuration on my computer that applies to "all Debian repositories". for #1, i came up with something along the lines of [1], which basically just ignores .gitignore on a per-repo basis (configured via `git config`) in a way it works, but has some unwanted side-effects (like a no-longer working tab-completion for git) for #2 i was happy to see that recent versions of gbp (currently in experimental) sport a postclone hook [2], which can be used to run various repository tasks right after cloning. i now use this to gitignore "/.pc/" via .git/info/exclude (not touching the .gitignore file). unfortunately the two proposals clash (ignoring .gitignore really means ignoring all gitignore(5) files, including .git/info/exclude). so i'm not sure about a proper "best practice" to deal with this. i could imagine something like: - add ".gitignore" to the Files-Excluded stanza in d/copyright *without* warranting a "~repack" suffix in the version (i guess this is justified, since dpkg-source ignores the file anyhow). even better would be to nag the developers of gbp to just not include this file on import-orig (i'm not sure about the prospects of this suggestion though). - suggest (in [3] to use a postclone hook that ignores Debian-toolchain artefacts via .git/info/exclude even better would be to nag the developers of gbp to automatically ignore /.pc/ if the source-format is "3.0 quilt" (i've already done that [4], but it seems that with the advent of postclone hooks they think this is none-of-their-business). what do others think*? fgmasdr IOhannes [1] http://stackoverflow.com/questions/25909293 [2] https://bugs.debian.org/812816 [3] https://wiki.debian.org/DebianMultimedia/DevelopPackaging [4] https://bugs.debian.org/812815 * apart from "don't you have other problems?" _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers