Re: Standardizing the layout of git packaging repositories
Le Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog a écrit :
>
> while git is the most popular VCS for packaging, there's no clear rules
> on what you can expect in a random git packaging repository listed
> in Vcs-Git. I would like to fix this so that:
> - we can extract more useful data from the git repositories
> - we can more easily share our git repositories with upstreams
> and downstreams
> - we start to converge on some conventions even though we might
> continue to use different git helper tools
>
> I want to use the DEP process for this. But before I can write a first
> draft I would like to have your ideas of what we should include
> in such a document.
Bonjour Raphaël,
I think that it is a good idea to propose a standard that packaging team and
individual developers can follow optionally if they like it. In the Debian Med
packaging team, I would be glad to be able to replace the guidelines in our
group with a pointer to the DEP that you propose to write.
Here are a few comments.
Regarding the name of the branches, I think that it would be preferable to
systematically use a prefix, ‘debian’, and I think that ‘debian/unstable’ is
more consistent than ‘debian/master’. For the backports, I have been using
‘debian/wheezy-backports’, etc. Altogether, the pattern is ‘debian/suite’.
The ‘pristine-tar’ branch, while mostly used for Debian, is universal in
principle (who would knowingly release a tarball with the same name and a
different content from an alreadly circulating tarball ?), and therefore
probably does not need a ‘debian’ prefix. Pristine-tar has been useful to
avoid preparing an upload with a tarball that has the same content but a
different MD5 sum than the one in the archive (because of time stamps, etc).
The interest for this is a bit reduced now that we have source-only uploads
(which are easier to prepare), but I think that it is still a good thing to
have for source packages based on upstream tarballs.
The ‘upstream’ branch generated and used by the tools from ‘git-buildpackage’
is usually different from the master branch of the upstream Git repository when
it exists. While this branch name is well-established in Debian, I think that
it is misleading and for my new packages I try to avoid it. When it is still
necessary to import upstream tarballs, I would rather use a name under the ‘debian/’
prefix. When the upstream master branch is enough, I prefer to leave it under
the name ‘master’.
Of course, the Debian clones of the repository should use a debian branch by
default, like ‘debian/unstable’.
For the Debian tags, I think that we definitely need a prefix, as I have seen
upstream releases like 1.0 being followed by 1.0-1… The tag prefix <debian>
can be seen as identifying the distribution or the format; I would not mind if
there were Ubuntu packages tagged with a <debian> prefix.
The following is probably too rarely used to standardise, but maybe somebody
has an insightful comment to make ? I have been storing build logs in the Git
repositories of some source packages I maintain. At the beginning, I called
the branch ‘meta‘ and had all the logs in the same branch, and later I tried
things like debian/logs/unstable to separate suites, or build/amd64, etc, with
one log in each branch, so that ‘git diff’ can do the right thing.
Lastly, perhaps off-topic, would it make sense to give a recommendation on how
to manage upstream sources that use Git and ‘gnulib’ ? I have met such a
situation, where the version number of the program was not availalbe in any
other way than through a Git tag, and could not find better than importing the
release tarball with ‘git-import-orig’ instead of following Upstream's master
branch.
Have a nice week-end,
Charles
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: