On 30/06/19 00:16, Ian Jackson wrote:
> Enrico Zini writes ("Re: Survey results: git packaging practices / repository
> format"):
>> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
>>> I hope you all won't mind too much that Sean and I have privileged our
>>> own point of view, in the columns which contain value judgements, and
>>> that we hope to retain that property of the page.
>>
>> I have no problem with you making a collation of the results from your
>> point of view, but I would also like to see some more objective
>> presentation of the survey results, even if in a more raw format.
>>
>> I saw in your survey a great potential for documenting the existing
>> workflows, and I'm having a hard time getting that documentation from
>> the current presentation.
>
> The current presentation lists *branch formats* not *workflows*.
>
As a lurker and pervasive packager of the downstream Devuan, I thought
I'd share some of my thoughts on this as git has been the core of our
work flow and build system.
For background ref, Devuan uses git for all packaging. We've never
supported building from anything other then git sources. All our
packages are built straight out of our git repository using Jenkins ci
with Jenkins-Debian-glue (jdg)
The jdg splits the package building into 3 separate phases - source
build (uses gbp), binary build, and uploading to our repository (dak)
For the most part we are trivially patching the Debian packaging to
change the build to remove hard dependencies on systemd, and to build
some Devuan specific packages for themes and other minor tidbits. (It's
a really small subset of packages.)
Our packaging approach is more or less "unapplied" for 3.0(quilt)
packages, and (I think) pretty much universally using quilt and gbp -
only for changelog and buildpackage (because it does a nice pbuilder
based build process with all the checks for ensuring no stray patches to
the upstream source sneak in).
We've universally stamped out using pristine tar ;-) and always use use
either upstream-branch or preferably upstream-tag. This works pretty
well and we can usually merge from salsa (and formerly alioth) tidy up
the changelog conflicts.
our branch structure is basically
suite/<codename*>[-proposed]{[-updates][-backports][-security]}
where the codename is either the target suites codename, "unstable" or
"experimental" the optional suffixes [proposed] etc only apply really to
stable and testing release branches in the same way.
For upstream branches (where they exist) they are named the same as the
upstream branch and tags in Debian (except for where we have unpacked
the pristine-tar branches).
For native packages we just patch and merge from Debian - this really
only applies to Debian-installer and related packages.
For Devuan we only care about suites/<suite-name> and any upstream
branches and discourage private development branches being pushed to our
"Devuan-packages" group.
Most contributions come via forks and merge requests in our gitlab instance.
A few personal thoughts on where things might go in a way that will be
helpful to downstream/derivatives:
(Most of these stolen or inspired from DEP14 -
https://dep-team.pages.debian.net/deps/dep14/)
- Packaging branch names <vendor>/<suite|codename>
- Release tags: upstream/<version> and <vendor>/<version>
(upstream tags are the easiest)
A debian/README.source that describes how and where the sources obtained
and any alterations such as removed non-free content.
Upstream sources in the "upstream/" namespace
I did spend some time trying to make 3.0 (git) - aka "gitsrc" packages
work, with some limited success, but mostly abandoned that in favour of
quilt or native for any Debian packages. That said I think if the
tooling (gbp particularly) could recognise and handle 3.0 (git) packages
properly it would be useful. (See https://wiki.debian.org/GitSrc for
more info)
There was one outstanding issue in the "gitsrc" discussion that I had,
and that was clear handling of patches to the upstream source. The best
answer I can come up with that is to use a sub vendor namespace
"patches" and a branch per patch
ie "debian/patches/01-<brief-descriptor>"
This retains a similar form and workflow as quilt and patches could be
applied and managed with the same flow as quilt does - possibly with a
re-worked quilt. The benefit also is that it becomes easy for git to
directly identify patch clashes and allow to easily resolve them using a
similar workflow as is done with quilt packages. Ideally a quilt like
tool would do this for us).
In addition the gitsrc format would not have to ship the upstream source
at all if a machine-readable file containing the upstream source vcs or
archive url that could be used to automatically obtain and generate the
orig.tar archive at build time (if the orig.tar archive didn't already
exist locally or in the Debian archive/pool)
I hope this adds some light and information into the mix.
-- Note:
I'm interested in where this discussion is going and will attempt to
follow it to it's conclusion. However I'm infrequently looking at
debian-devel posts, so if anyone wants to specifically bring my
attention to pertinent details in this thread, or wants a more
synchronous response, feel free to CC me.
Cheers,
Daniel
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
signature.asc
Description: OpenPGP digital signature
