[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote:

>Here's the draft:

Thanks for getting this started.  I think it will help considerably to get
some standardization here.  I would think that as more teams adopt git, they
will eventually just refer to DEP 14, perhaps with some additional team-based
deviations if necessary.

One question: when this gets adopted, will individual maintainers or teams
have to know which of the git packaging helpers a particular repository is
using?  IOW, what happens if I were to use gbp-pq on a package that someone
else had used git-dpm on?  Do we need some kind of convention to detect which
helper is being used?  I wouldn't want to restrict choice by defining a
standard Debian-wide (but it's okay within the context of a team).  I just
want someone who walks up to a git repo to at least easily know which tools to

>Vendor namespaces
>Each "vendor" uses its own namespace for its packaging related 
>Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and
>so on.

My question is whether the vendor namespaces are overkill for the majority of
packages, where there probably will be just one vendor (i.e. Debian).  Should
DEP 14 allow for a simplified layout such as master, pristine-tar, upstream
when there is no other vendor involved?  Allowing for master as an alternative
to debian/sid or debian/master might simplify the common case.

However, I'll also note that for pycurl, I'm currently using master to be the
Debian unstable branch, and ubuntu to be a small set of deltas on top of that,
for the current Ubuntu development series.  If I needed to support older
releases in either distro, then debian/wheezy or ubuntu/utopic would be good
branches to use.  (Or IOW, what's the equivalent of debian/sid for Ubuntu?)

>  QUESTION: some people have argued to use debian/master as the latest
>  packaging targets sometimes sid and sometimes experimental. Should we
>  standardize on this? Or should we explicitly allow this as an alternative?

It makes some sense to allow this as an alternative, but then my question
about using 'master' as an even simpler alternative for the common case should
also be asked.

>When releasing a Debian package, the packager should create and push
>a signed tag named `<vendor>/<version>`. For example, a Debian maintainer
>releasing a package with version 2:1.2~rc1-1 would create a tag named
>`debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with
>version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should
>point to the exact commit that was used to build the corresponding upload.

Agreed.  Tag namespaces certainly make a lot of sense.

>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.

Similarly, is 'upstream' okay for the upstream branch?  It's a little simpler
than upstream/latest, especially if you don't anticipate importing an other
upstream branches.

Again thanks.  After Jessie is released, I hope to restart this discussion
over in Debian Python, for that team's transition to git.


Attachment: signature.asc
Description: PGP signature

Reply to: