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

Re: libgsl stuck, can anybody help?

Hi Dirk,


Hi Rudi,

This is probably a question for debian-release or debian-devel and not
debian-science ...

I'll try to answer this from my vantage point, and I think that vorlon may
correct any crass inaccurracies I state here.

On 5 September 2007 at 06:07, Rudi Cilibrasi wrote:
| Hi everybody,
| | I have been trying to do a new release of "libcomplearn", a package I 
| have had in Debian but recently has fallen out of date because it is
| stuck behind the dependent libgsl package.  Unfortunately, the libgsl
| package has been stuck for 55 days now [1]:

1. gsl builds everywhere and has been built everywhere (see the buildd page
   hanging off the QA link you give in [1])

2. There are no 'excuses' (http://qa.debian.org/excuses.php?package=gsl)

3. And the winning answer is as usual provided by 'why is package X not in
   testing yet': http://bjorn.haxx.se/debian/testing.pl?package=gsl

   Checking gsl
trying to update gsl from 1.9-3 to 1.9-5 (candidate is 55 days old) 
   Updating gsl makes 39 depending packages uninstallable on i386: adun.app,
   asymptote, bogofilter, bogofilter-bdb, bogofilter-qdbm, bogofilter-sqlite,
   dieharder, gmsh, gpiv, gpivtools, kst, kst-plugins, libgpiv2, libgpiv2-dev,
   libgsl-ruby, libgsl-ruby-doc, libgsl-ruby1.8, libmeep-dev, libmeep-mpi-dev,
   libmeep-mpi1, libmeep1, libocamlgsl-ocaml, libocamlgsl-ocaml-dev,
   liborsa0-dev, liborsa0c2a, meep, meep-mpi, orpie, pd-pdp, pdl, pspp, qtiplot,
slang-gsl, snd, snd-gtk, xorsa, yacas, yacas-proteus, yorick-yeti-gsl 
   Updating gsl makes 2 non-depending packages uninstallable on i386:
   libgimp-perl, med-bio

This is what we call a library transition, and it doesn't work piecemeal. So
if you feel energetic, try to figure out what the issue is with those 39 + 2
packages listed above, and offer help on those.
But one can think also about a scenario where gsl gets a "manual kick" to enforce its entry into a release development stream. And then the 39 + 2 package cannot enter and the message "please adapt me for libxyz-k.l.m compatibility". This would highlight the 39 + 2 packages which then can be adapted step by step. 

The same could happen to one or the other basic library too.
But only after a decision, that's why I wrote "manual".

Kind Regards,
Thomas



Delays happen.  We have many libaries, and many interdependencies.
Sorry, 
Dirk
(gsl maintainer)

| I have tried emailing a few people, but have not had any luck figuring
| out how to help get libgsl unstuck.  I have also not found any
| (certain) evidence that progress is being made.  apt-cache rdepends
| indicates that there are dozens of packages dependent on libgsl0 or
| libgsl0ldbl and so I am beginning to be concerned that we are building
| up a lot of delay.
| | Can anybody reading this shed light on what the next logical step 
| would be here to unblock libgsl?  I am a new maintainer and so have
| not dealt with this issue before.  It is essentially blocking most of
| my Debian efforts, however, because almost all of my packages depend
| on libcomplearn.  Any help is much appreciated,
| | Rudi | | [1]: http://packages.qa.debian.org/g/gsl.html | | | -- | "We can try to do it by breaking free of the mental prison of 
| separation and exclusion and see the world in its interconnectedness
| and non-separability, allowing new alternatives to emerge."
| | | -- | To UNSUBSCRIBE, email to debian-science-request@lists.debian.org 
| with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
Reply to: