(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)
Hi, 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 comments: 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 releases. > > 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! Cheers! And thanks again for your comments! Carlos -- +----------------------------------------------------+ 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: cpasc...@cells.es Phone: +34 93 592 4428 +----------------------------------------------------+