Hi, 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 diverse. - 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 backports.org). - 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 non-DD). 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): http://lehobey-rennes.dyndns.org/dokuwiki/doku.php?id=doc:dak:dak You can look at the dak bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=dak&archive=no&version=&dist=unstable 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: http://wiki.debian.org/HowToSetupADebianRepository 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