Re: [Debian-astro-maintainers] Contributing LIGO software to Debian
On Tue, Mar 21, 2017 at 09:25:34AM +0100, Ole Streicher wrote:
> Hi Leo,
> On 20.03.2017 21:54, Leo P. Singer wrote:
> > I am part of an experiment called LIGO, Laser Interferometer
> > Gravitational-wave Observatory , that uses laser light to detect
> > and study gravitational-waves, ripples in space time produced by
> > collisions of black holes. I want to offer to contribute our
> > project's software stack to Debian-Astro. This would lower the
> > barrier of entry for researchers and students to work with LIGO
> > data.
> That is really a great idea, exactly this is one of the goals of our
Awesome. It would be a pleasure to me if I (as a physicist by
profession but moved along to other topic) could provide some
minimum help to make this project a success.
> > Our software mainly consists of LALSuite , a collection of several
> > C and Python packages that provide tools and libraries that are
> > coarsely organized by scientific topic. Our collaboration already
> > generates Debian packages (as well as RPMs) to deploy our code on our
> > Debian (as well as Scientific Linux) computing clusters. I am not a
> > maintainer of any of these packages myself, but I am a frequent
> > contributor on both the codes themselves and the Debian packaging. I
> > would probably be involved in some way in actually uploading the
> > packages to Debian.
> > I have a few questions about how to get this process started. We keep
> > our Debian package source in our own public source repositories. We
> > prioritize developing for the current stable Debian release because
> > that is what we run on our clusters, although I have made sure that
> > at the moment everything builds Lintian-clean on testing and unstable
> > as well.
Sounds really good. I was once in a situation to help migrating the
software of a biology lab to Debian (work done inside the Debian Med
> > How would this work with Debian-Astro's model? Would we need
> > to have a mirror of our source code on Alioth, for example?
> Debian Astro are actually a number of closely related things:
> * a mailing list (firstname.lastname@example.org) to discuss user and
> developer questions related to astronomy
> * a packaging team (on alioth; with the debian-astro-maintainers list)
> * a Debian Pure Blend (with a web page, tasks to ease installation etc.)
> Ideally, all of these are used together. However, this is not a strict
> requirement. If you want to maintain the LIGO packages yourself, this is
> possible as well. But then we will lose an important feature, which is
> team maintenance. For others, it is much more difficult to provide
> patches for the LIGO packages, or to create and upload a bugfix if the
> repository is somewhere else.
> We had exactly this problem with some packages of the Neurodebian team
> at the end of last year: several of their packages had RC bugs (and were
> already scheduled for autoremove, so that they would be excluded from
> Debian Stretch), but they didn't have the manpower to fix them. At the
> end, they agreed to move the packages to the debian-science team (and
> the git repository to alioth), so that we could fix them together.
> This may be not so important for very specific packages, but many
> required dependencies are later also used more commonly, and there we
> could run into trouble.
> So, you are free to maintain them yourself (and just upload to Debian),
> or to to team maintenance (and *move* the development repository to
> alioth), but keep that in mind, and for common packages please strongly
> consider moving to team maintenance. It also helps to provide simple
> patches, like test cases or journal references.
> Andreas, would you add something here, or do you disagree?
I fully agree and for the moment I have nothing to add. As far as I
understood Leo the intention is to make the software easier accessible
to Debian users. Using the Debian infrastructure consistently has
advantages to accomplish this mission. The idea of Debian Pure Blends
is simply to integrate fully into Debian and the Debian Astro team is
doing this for this kind of software.
> What concerns the distribution (stable vs. testing/unstable): it makes
> much sense to "backport" the packages once they are in testing, so that
> you can provide versions for the stable release as well, as you already
> started for astropy.
Also here full agreement. I made some quite good experiences with
> > On a more technical level, I wanted to ask about one particular
> > package of ours, glue. It's a dependency of most of our Python
> > software and provides I/O and workflow management ("glue" code). It
> > conflicts with the existing python-glue package . Would it be
> > sufficient for us to rename our package python-logo-glue and declare
> > the conflict in the control file?
> That is a real problem. Technically, the package could be Priority:
> Extra and declare the conflicts; however this will prevent people from
> installing your "glue" and the glueviz "glue" together. Since they both
> play in the same area, this may actually decrease user experience. I
> must say that am not sure if I would sponsor a conflicting "glue"
> package andwould strongly recommend that you contact the glueviz
> developers to resolve the conflict upstream. Wouldn't ligoglue (or
> something similar) a solution also for the Python package name?
I agree with Ole that conflicts should be avoided if possible. Talking
to upstream should be the first step. I do not know glue upstream but
usually issues brought up by Debian maintainers are regarded as worth
considering. If there is no chance to find a common solution I'd agree
with Ole again to do a proper rename which does not create any conflict.
Conflicts are just bad and sooner or later you might run into the
situation that some tool might need the original glue and you can not
use this tool in this case. In short: Avoid conflicts whereever
Regarding the help I could provide: To upload a Debian package to the
official Debian mirror you need a Debian Developer to sponsor the
package. I know that Ole is quite quick in doing this and thus I do not
remember any Debian Astro sponsering request in my offer to sponsor any
Blends packages. If there should be any bottleneck in sponsoring I'd
be at your service.
BTW, I had done some Debian packaging workshops at MPI. If needed I
could do so also at your institution (even if the existence of lintian
clean packages sounds like this is not needed).