Re: Feedback request about the Alba Upstream to Debian packaging effort
(Hi. Sorry if you already got this message. There was some problem with my
previous attempts to reply, so I am trying again after our email admin changed
I work at the Alba Synchrotron and I authored the presentation that Frederic
sent (thanks to him for initiating this discussion). I'll try to reply to some
On Sunday, June 3, 2018 1:07:26 PM CEST PICCA Frederic-Emmanuel wrote:
> Hello Ian
> > I reviewed the version number proposal and it seems sound to me.
> It just comes to my mind that Maybe it does not fit well with my convention
> for exeprimental numbering whcih is
> so maybe the best way would be to use
So, you would not use the "bpo9" part for the packages built for stretch?
> > I have some observations:
> > You probably want to keep the delta between the upstream and the
> > debianised branch as small as possible.
> Yes you are right this should be kept as small as possible.
Not sure if I understand well, but I think that this is exactly what we
achieve for the packages for which we are upstream and we use the whole
pipeline (including upstream-packaging-and deploy)
> > On build systems and debian/ruless: if (i) you can get as much of your
> > upstream build system looking as standard as possible (ii) you can get
> > as much of the rest supported by dh as possible, then your
> > debian/rules files could possibly be very small indeed.
This is generally what we have.
> > debian/changelog is a bit of a pain and you will have to write code to
> > generate it. [gbp-]dch can be helpful.
> gbp allows to generate this automatically, but this is true that the quality
> of the changelog is not necessary good. Most of the time because the commit
> are not that great either...
That is exactly our approach. We let gbp dch do its magic and it is mostly a
matter of educating ourselves to do adequate commits when committing to the
Our goal is to have "not-terrible" automated changelogs for our local packages
but rely on manual editions (via a dedicated commit)) before public debian
> > Ideally you would treat debian/control as an output file: generate it
> > entirely from upstream stuff, using some tool, and commit the result
> > as a committed-artefact to the debianised branch.
> I agreed with you that it would be great to have a way to generate a debian
> package from the upstream git repository and some minimalist metadata
> purely descriptive.
> > Your debianisation tool becomes part of the source code for your
> > packages. You need to publish it in your repository, track the
> > version used, etc. So it probably needs to be debianised. I think
> > you need to mention it in Built-Using or something similar.
> good point, but for now this is just the gitlab file.
> Do you think that the guix way can be modified in order to generate Debian
> packages instead of guix binaries ? I like a lot the idea to maintain only
> the metadata in a repository. Indeed in our case scientific software are
> most of the time not that standard and need lot's of tweak in order to be
Auto-generating the package would be a good addition, but as Fred says, it is
out of the current scope.
That said, we do use some scripts that automate the debianization of our
python upstream sources (and also creation of the repos, etc). For now these
are too tied to our local infrastructure. I see a lot of room for improvement
and generalization in this area.
But still, in our experience, full automation of the first debianization of
anything-but-trivial packages is too hard. So our approach is to assume that
the first debianisation is done *before* we apply this pipeline
> > Finally, and VERY CONTROVERSIALLY: consider whether you want to bother
> >> > with source packages. You could just use git branches instead.
> > Source packages are a pain.
> Just use dgit ;)
The source packages are created in the "upstream" part of the pipeline and are
of interest only to upstream (and totally optional). They are not used at all
in the debian packaging part of the pipeline. For the packaging, we use git
branches and merges only (see https://people.debian.org/~picca/gitlab-ci.yml )
> > Good luck and have fun!
And thanks again for your comments!
Carlos Pascual Izarra
Scientific Software Coordinator
ALBA Synchrotron [http://www.albasynchrotron.es]
Carrer de la Llum 2-26
E-08290 Cerdanyola del Valles (Barcelona), Spain
Phone: +34 93 592 4428