Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Ron,
On Wed, 12 Nov 2014, Ron wrote:
> I think you probably need to be careful of overspecifying this.
Definitely. That's precisely why I don't want to dwelve (too much)
into details of the various workflows and why I try to restrict
the DEP at simple naming conventions for branches and tags that
the various tools might need.
> The "normal workflow" is simply: work in git exactly how you normally
> would, whether you're making upstream changes or debian patches.
> Export a source package with `gitpkg $debtag $upstreamtag`.
[...]
> The good news from all that though, is that it would seem unlikely
> that gitpkg itself would need any changes to be able to cope with
> any repo design you could come up with that wasn't completely insane :)
Great, then it might be that gitpkg doesn't need any code update
and that only its documentation should be updated to recommend
using the default names when creating $debtag (and $upstreamtag in
some cases).
> The bad news perhaps, is I'm less convinced about how keen people
> already using gitpkg will be to arbitrarily restructure their entire
> existing repos to follow this. At least not without some much clearer
> rationale about what compelling benefits they'd get in return for all
> that work and disruption and rewriting of history.
I don't necessarily want everybody to update their current repositories
(altought it would be nice). I want at least that when new contributors
create a new git packaging repository, they have some good advice on
how to structure their repository and the helper tools that they
pick work nicely in that layout.
> Maybe I missed something somewhere (I should have been sound asleep
> a few hours ago, so that's quite possible), but I see lots of
> explanation of *what* you want to do, but not the killer reasoning
> about *why* you want to do it, or what concrete things you think
> will be gained from it.
I think I explained my goals in the introduction of the DEP. Making
it easier for Debian and its derivatives to build upon their respective
Git repositories (possibly on a semi-automated basis). And making it
easier to switch between various git packaging helper tools because they
would share (by default) the same basic conventions. And making it easier
to have the upstream git branches in the packaging repository too.
> More specifically, you have things like:
>
> "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"
>
> This seems like a git-bp specific hack to me, that has the assumption
> and trained habits of using that tool so deeply embedded in it that
> doesn't bother to explain why you would use this, when you would use
> this, or even what you would expect it to do.
Given that the DEP recommends to create tags like <vendor>/<version> it
seems like a good idea to explain how to retrieve <vendor>, no?
It's not really related to git-bp (except for the fact that git-bp
started this convention of prefixing the tags with "debian/"). gitpkg
might not take the job of creating that tag, in which case that
particular advice is obviously irrelevant and it's up the package
maintainer to follow that naming convention when he manually creates the
said tag.
> The section on "Patch queue tags" also seems to be written from the
> perspective of only knowing one tool and one workflow to use it.
> With the work that David Bremner did on git-debcherry, gitpkg can
> fully automatically extract a quilt patch series for a source package
> simply from completely normal commits to your repo, in a form that
> makes them trivial for upstream to cherry pick, and makes them
> automatically vanish when you merge the upstream release that includes
> them.
Yes, the pach queue section is heavily inspired by "gbp pq" but again it's
nothing mandatory. It says something like "if the helper tools produces
something that looks like a patch queue branch and if it wants to store it
for later consumption, it should use that tag name".
Fine if the other tools do not need anything like that. But who knows,
maybe you will want to enhance git-debcherry to not only update
debian/patches/ but also store the corresponding git branch for long-term
storage. In which case, you will already have a recommended tag name
for this purpose :-)
> > I would be willing to participate to such a sprint and do my share
> > of the work (although I'm primarily using git-buildpackage and would
> > likely start with this helper tool).
>
> I am a bit curious about what patches you think you're going to need
> to make to make things comply with this plan?
For gitpkg? I don't know. See above, maybe it's just documentation update.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Reply to: