Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* Raphael Hertzog <hertzog@debian.org> [141111 22:26]:
> Helper tools should usually rely on the output of `dpkg-vendor --query vendor`
> to find out the name of the current vendor. The retrieved string must be
> converted to lower case. This allows users to override the current vendor
> by setting `DEB_VENDOR` in their environment (provided that the vendor
> information does exist in `/etc/dpkg/origins/`).
Is using the vendor you use git on a good default for the vendor code
you are currently working on? In my experience those two are quite
unrelated.
> Version mangling
> ----------------
>
> When a Git tag needs to refer to a specific version of a Debian package,
> the Debian version needs to be mangled to cope with Git's restrictions.
> The colon (`:`) needs to be replaced with a percent (`%`), and the tilde
> (`~`) needs to be replaced with an underscore (`_`).
Is there a previous case of encoding colons with percent signs?
If it is inventing a third way instead of using on of the existing ones,
is sounds like a bad idea.
> Packaging branches and tags
> ===========================
>
> The Git repository listed in debian/control's `Vcs-Git` field should
> usually have its HEAD point to the branch corresponding to the
> distribution where new upstream versions are usually sent. For Debian,
> it will usually be `debian/sid` (or sometimes `debian/experimental`).
I think this should alternatively allow for Vcs pointing to that branch
instead. It sometimes makes sense to put the debian package development
branches in the same repository as the upstream branch, where HEAD might
be reserved for the upstream branch.
> When releasing a Debian package, the packager should create and push
> a signed tag named `<vendor>/<version>`.
I'd advocate s/signed/(possibly signed)/, as I'm not ready to sign such
a wildcard with any valuable key and getting another very-low-security
key just to have signed keys to match this proposal sounds like waste.
Tags are only based on versions are also quite hard to shuffle around.
I'd strongly suggest adding the name of the source package to those,
otherwise accessing multiple packages in on repository causes a big
mess. (git keeps branches in the per-origin "remote" namespace when
fetching stuff, tags only have one global namespace, local and remote).
> Managing upstream sources
> =========================
>
> Importing upstream release tarballs in Git
> ------------------------------------------
>
> If the Git workflow in use imports the upstream sources from released
> tarballs, this should be done under the "upstream" namespace. By default,
> the latest upstream version should be imported in the `upstream/latest`
> branch and when packages for multiple upstream versions are maintained
> concurrently, one should create as many upstream branches as required.
>
> Their name should be based on the major upstream version tracked:
> for example when upstream maintains a stable 1.2 branch and releases
> 1.2.x minor releases in that branch, those releases should be imported
> in a `upstream/1.2.x` branch (the ".x" suffix makes it clear that we are
> referring to a branch and not to the tag corresponding the upsteam 1.2
> release). If the upstream developers use codenames to refer to their
> releases, the upstream branches can be named according to those codenames.
>
> Helper tools should detect when the upstream version imported is lower
> than the latest version available in `upstream/latest` and should offer
> either to create a new branch (based on the highest version available in
> the history that is still smaller than the imported version) or to pick
> another pre-existing upstream branch.
I'm very sceptical about this part. I'm not sure it is worth
standardizing and it seems quite a lot of work to implement something
like that (which I expect I'll have to override more often than not
if using such an helper).
> Importing upstream releases from Git tags
> -----------------------------------------
>
> When the packaging branches are directly based on the upstream Git
> branches, upstream usually also provide proper Git tags that can be reused
> for official releases.
>
> If helper tools have to identify the upstream commit corresponding to a
> given upstream release, they should be able to find it out by looking up
> the following Git tags: `upstream/<version>`, `<version>` and
> `v<version>`.
>
> The `upstream/<version>` tag would be created by the package maintainer
> when needed: for example when it does a release based on a Git snapshot or
> when the tag naming scheme used by upstream is not following the above
> rules.
That lacks possibility three: importing tar content on top of upstream
branches. And again adding the source package name in there would be
nice.
> Native packages
> ===============
>
> The above conventions mainly cater to the case of non-native packages,
> that is when the upstream developers and the package maintainers are
> not the same set of persons.
>
> When upstream is Debian (or one of its derivative), the upstream vendor
> should not use the usual `<vendor>/` prefix (but all others vendors should
> do so). The main development branch can be named `master` instead of
> the codename of the target distribution (although you are free to still
> use the codename if you wish so).
Does native here mean a native package or a package developed primarily
for Debian (which can also use a non-native packaging)? This paragraph
seems to mix those two concepts quite a bit.
> Patch queue tags
> ================
>
> A patch queue branch is a (temporary) branch used to define the set
> of upstream changes that the package will contain, its content is
> generally used to later update `debian/patches` in the resulting
> source package.
s/(temporary)/(possibly temporary)/ ?
> What to store in the Git repository
> -----------------------------------
>
> It is recommended that the packaging branches contain both the upstream
> sources and the Debian packaging. Users who have cloned the repository
> should be able to run `dpkg-buildpackage -b -us -uc` without doing
> anything else (assuming they have the required build dependencies).
++
(except that one of course needs to get the .orig.tar.gz using
pristine-tar or uscan for a non-native package needs to be an exception
from "anything else")
> Managing debian/changelog
> -------------------------
>
> This DEP makes no specific recommendation on how to manage the Debian
> changelog. Some maintainers like to use tools like `gbp dch` to generate
> the changelog based on Git commit notices, others edit the file manually
> and use tools like `debcommit` to reuse the changelog entry in the
> Git commit.
>
> Helper tools should however configure the Git repository so that merges
> of the `debian/changelog` file are handled by `dpkg-mergechangelogs` as
> this will make it much easier to merge between different packaging
> branches.
Ugh. Please do not encourage tools to pester with my git config.
(Perhaps this want meant as something to do when automatically creating
a repository for you?)
Bernhard R. Link
P.S: I think the timing for this proposal it not that good. I'd rather
waste my time looking for some RC bugs to fix as long as there might
still be some easy ones left so shortly after the freeze.
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Reply to: