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

Re: How much interest in a "debian-science.org" repository?


First, I have created a new wiki page to keep track of this
discussion: http://wiki.debian.org/DebianScience/UnofficialRepository

On Wed, Jul 19, 2006 at 12:50:56PM -0400, Kevin B. McCarty wrote:
> On 7/19/06, Frederic Lehobey <Frederic.Lehobey@free.fr> wrote:

> >We have discussed exactly the same idea at the `science' session of
> >LSM/RMLL (http://www.rmll.info/theme_26) with people already on this
> >list.  So let's join our forces.

> I can't find any slides at that web site, just talk names.  Will
> slides or minutes be available later?

Hopefully yes.  The discussion occurred during the round table of
Friday though, so do not expect much more minutes than those I will
try to produce from my memories.  Other participants might obviously
add their own too.   :-)

Attendants who have taken part to this point of the discussion _and_
showed interest for the future are:

  Lionel Mamane (DD)
  Laurent Fousse (DD)
  Yannick Patois
  Frédéric Lehobey (myself)
  Thomas Petazzoni (for the packaging / repository aspects, not
specifically for science)

  (have I forgotten someone?)

About 15 people participated.  One part was on the experience people
packaging scientific application (people doing this for Debian and
Mandriva were there) had with their upstream.  It was quite close from
what you explain there:
http://people.debian.org/~kmccarty/physics-software-rant.html so I do
not go more into details.  It has been asked for a kind of `packager
manifesto' explaining to upstream what were the packagers expectations
and sharing the best practices (you know, things like POSIX,
portability and such...).  ;-)

An other point of the discussion was on scientists (software users)
expectations and they are somewhat contradictory.

 - People when using packages wish them to closely follow upstream
(like a package build daily from the cvs or equivalent).

 - But in the same time they wish them for the stable distribution.
They want it globally stable but very unstable for the specific
software they are tracking for their day to day work.  So this mixes
quick packaging procedures and backport needs.

 - As a corollary they want to install several versions of the same
software on their system _simultaneously_ (like foo and foo-cvs, but
also foo-1.7 that has been used for this experience and foo-2.3 for
the one in preparation).  It is nothing to say that the packaging (and
the goal of the Debian distribution itself: one -- good -- version of
the software for a stable distribution) does not make that goal easy
without much work of the packager.  And upstream ways (if any) to deal
with such concurrent installations of their software might be quite

 - Once involved in an experience, they can keep the package (at its
version) for a very long time, much longer than one (or even two and
more) Debian release cycle(s).

With respect to a common / unique / central repository.

 - Yes, it would be much easier to have something similar to
http://www.debian-multimedia.org/ (a unique repository instead of many
ones, more or less maintained).

 - Available for several distributions (stable, testing, etch, Ubuntu
current and previous one, even Fedora or whatever...)

 - They accept some instability under the condition it is possible to
come back to a previous working version. (Again, needs similar to

 - They do not care much about the licence problems (non-commercial,
incompatibilites, lack of licence). (For the record, I DO!)  :-)

(The followings are more my own conclusions from the discussion.)

 - Need for quick availability of the package (even if not suitable
for Debian main).

 - Package being in testing is a bottleneck for backports.org.

 - Sponsoring (for Debian main) is a bottleneck for _scientific_
software (hence the debian-science repository should allow upload from

I think all those different goals might be covered by a common
repository with its sections properly labelled (but a proper labelling
is not so easy to design, as it depends on each user point of view).

> >I had in my plans to investigate reprepro and mini-dinstall to see if
> >they could fit our needs (multiple uploaders...).  I have some
> >experience with dak but it is not so easy to setup properly (and the
> >current package in the archive is in need of care).
> I was thinking of dak, mainly because (to the best of my knowledge)
> once set up, it requires very little care and feeding on the part of

I we were to finally to decide to go for dak, I would be happy and
willing to help you any ways.  Recent users of dak (they have set up a
new dak infrastructure) are debian-edu/skolelinux and backports.org (I
have asked the latter people for their actual dak setup but it seems
they have been too busy to answer me).

> the repository maintainer - I think all it needs is a GPG keyring for
> the people who will be uploading.  But if you have any dak experience,
> it is more than mine :-)

You can find my several dak setups there (it is written in French):

You can look at the dak bugs:

I have once considered upgrading the packaging to the current dak in
cvs.  But I fear it is still a too heavy task for me (I am not
familiar enough with dak source code to port the _important_ patches
introduced by Joerg Jaspert while packaging dak to the cvs version,
which, moreover is a moving target).

>                           Can you comment on the ease of repository
> maintenance with the other software?  I only use apt-ftparchive and
> some hand-written scripts for my local repository, but it's very small
> and the scripts have to be run again every time a new package or
> version is added.

Not really.  I have only worked with dak (I am not yet satisfied with
my own settings) after I have started this page:


I believe reprepro has some interesting features (automatically
copying packages from other repositories).  I plan to explore it
deeply before the beginning of August.

mini-dinstall has be recommended to me by Debian developers (Pierre
Habouzit among others).

Best regards,
Frédéric Lehobey

Attachment: signature.asc
Description: Digital signature

Reply to: