Re: Standardizing the layout of git packaging repositories
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
> - how do we tag the package releases?
>
> - pkg/<version>
> (note: git-buildpackage uses debian/<version> but I find this confusing
> - shall we standardize the "pristine-tar" branch?
IMHO it should be reserved for pristine-tar usage (as in "don't use it for
something else"), but use of the pristine-tar tool should be optional at
best.
pristine-tar has been orphaned *upstream*, it has design problems, and lots
of real world issues. I'm seriously considering a "git branch -D
pristine-tar" on my packages :(
> - 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?
Please don't. It would be Really Troublesome should a package need to
switch from native to non-native, or the opposite.
If you're worried about an useless "master" branch, one can do away with it
with help of git symbolic-ref on bare repositories:
git symbolic-ref HEAD refs/heads/debian/master
will change a bare repo's default branch to "debian/master", you can remove
the "master" branch after that.
> - <version> encoding (due to git restrictions):
> ":" -> "%"
> "~" -> "_"
>
> - are there other important things to standardize?
What to do with packages that already adopt other schemes? A lot of
packages already use dgit, git-buildpackage, etc and have signed tags they
might want to preserve.
Also, tag namespace is shared with upstream, so it has to be somewhat
flexible in case the recommended scheme cannot be used.
What about commit and tag signing? Release tags ought to always be signed
really, but should we recommend something about commits or just ignore that?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: