Re: Team maintain Guile/Guix-related packages under debian-scheme?
Simon Josefsson <simon@josefsson.org> writes:
> I have to say that I do prefer the idea of bare debian/ repositories,
> but I never got that to work fluently in my own workflow, mostly because
> of tool issues that expects unpacked source code is stored in git.
For what it's worth, I currently prefer git-dpm[1], but I also work with
groups that primarily rely on gbp. More important, I'd say would be
finding an arrangement the people involved in the work are happy with.
(...and my situation is more complicated with say guile and emacs
because I have to (dfsg) split the package for emacs, and used to have
to version the packages for both, e.g. guile-X.Y (now only for guile).
git-dpm helps with that, allowing git do most of the heavy lifting when
working directly from the upstream branches/tags, which I do. And
since I want git to manage/maintain a dfsg split across releases via
merge, both sides of the split need to be in the same repo.)
In any case, I personally do think that where possible, working with the
upstream git branches/tags more directly is preferable, and so by
implication, including the full source is preferable, since I can then
fairly easily cherry-pick, merge, diff, rebase (e.g. patches, somewhat
automatically, via git and git-dpm), etc. I'm also more comfortable
with "patches applied", but that might depend on the tooling, i.e. with
git-dpm, the debian/patches/ dir is effectively automatically generated.
Basically, since I need to know git well in general, I'd rather be in a
better position to apply that knowledge to my packages too, when it can
help.
I also do wish debian would generally favor some debian-related prefix
for all the git references (tags, branches, etc.), e.g. deb/* to make it
easier to work in a repository that includes the upstream refs without
risk of collisions when you wan to.
For debian and guile, and going way back, I've used a (complicated)
strategy to allow maintaining packages that might be versioned and/or
split, and that might also need backports, etc., within a single
repository, e.g.
deb/guile-3.0/d/sid/master
deb/guile-3.0/d/sid/upstream
deb/guile-3.0/d/trixie/master
deb/guile-3.0/d/trixie/upstream
deb/guile-3.0/v/3.0.11
deb/guile-3.0/v/3.0.11-1
deb/guile-2.2/...
or for emacs, now that it's unversioned (it used to be emacsXY):
deb/emacs/d/sid/...
deb/emacs-non-dfsg/d/sid/...
...
Though I suspect it's not for (every|any)one...
[1] I don't actually know how commonly it's used these days, or whether
it'd be suitable for a broader group, but it's worked very well for
me for a good while.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: