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

Re: Standardizing the layout of git packaging repositories



On 08/15/2014 10:16 PM, Raphael Hertzog wrote:
> Some initial questions and possible answers:
> 
> - how do we name the various branches?
> 
>   - <vendor>/master for the main development trunk (aka unstable in Debian)
>   - <vendor>/<codename> for alternate versions
> 
>   The goal here is to be able to host in the same repository the branches for
>   multiple cooperating distributions (at least so that downstream can
>   clone the debian respository and inject their branches next to the
>   debian branches).

I generally use debian/unstable, but sometimes, it's best to follow
upstream (for OpenStack, I use debian/icehouse, debian/juno, etc.), so
there's no one-size-fit-all here.

> - how do we tag the upstream releases?
> 
>   - upstream/<version>
>   (note: we don't need an "upstream" branch, having the good tag for any
>   release that the distros are packaging is enough, it can point to a
>   synthetic commit built with tools like git-import-orig or to a real
>   upstream commit)

Why would you tag the upstream release? I mean, it's upstream's job to
do so, and it's natural to use their git tagging and their git
repository, no?

> - how do we tag the package releases?
> 
>   - pkg/<version>
>   (note: git-buildpackage uses debian/<version> but I find this confusing
>   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
>   don't need the vendor prefix as the usual versioning rules embed the
>   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
>   any conflict on the namespace, keeping a prefix is important to easily
>   differentiate tags created by upstream developers from tags created
>   by packagers)

Shouldn't ubuntu or kali use ubuntu/<version> and kali/<version>? I
don't see a problem here.

> - where should the HEAD point to in the public repository?

IMO, it should point to the packaging branch for Sid, but YMMV. Why is
this important?

> - shall we standardize the "pristine-tar" branch?

As in, always use pristine-tar? No! The point of using git packaging is
also to be able to use upstream git repo.

> - the above layout is for the traditional case of non-native packages,
>   what would be the layout for native packages? how can be differentiate
>   between native/non-native layout?

Sorry, which layout are you talking about? With pristine-tar? Well, I
don't think using pristine-tar is in any way "traditional", it's just
one of the workflow, which I always avoid if upstream is using Git and
has correct tagging.

> - <version> encoding (due to git restrictions):
>     ":" -> "%"
>     "~" -> "_"

I do use "~" -> "_" myself. Very useful.

> - are there other important things to standardize?

Yes. Producing orig.tar.xz out of upstream tag should be industrialized,
and written in "some" tools, which we would all be using. I currently
do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own
packages.

Thomas


Reply to: