[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
some settings)


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
> blablab_x.y.z-t~exp1
> so maybe the best way would be to use
> blalbla_x.y.z-t~~alba+1

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 
debian branch(es).

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
> packages.

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
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual@cells.es
 Phone: +34 93 592 4428

Reply to: