[Pkg-octave-devel] Forking glpk [was: Re: octave2.1 and octave2.9 in unstable]

[Rafael Laboissiere]

[Cc to the maintainer of glpk.  Falk: for the discussion context, see
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2005-November/000705.html
please.]

* John W. Eaton <jwe at bevo.che.wisc.edu> [2005-11-15 13:35]:

> On 15-Nov-2005, Rafael Laboissiere wrote:
> 
> | So, you are suggesting that we effectively fork the glpk package for our own
> | use.  Your suggestion above is quite sensible, in particular because this
> | new package will only be useful for Octave.  I will take a look at this when
> | time permits.
> 
> It would be best if we could avoid the fork.  How can we convince the
> maintainers of glpk that it would be best to generate shared
> libraries?  What are their objections?  Just that it is still under
> development?  Hmm.  Pretty much all software is under development, is
> it not?  I've never heard anyone say that shared librarires are only
> for software that is no longer changing.
> 
> If the upstream author won't accept your patch, then wouldn't it be
> best for the maintainer of the Debian package of glpk to apply it
> rather than have two glpk packages for Debian?
> 
> If neither will apply the patch, I don't see that we have much choice
> if we want to use glpk for Octave.

Although it is a waste of disk space (duplicated upstream tarball, for
instance), having two packages in Debian is not that bad.  This may be
the only feasible short-term solution for the octave2.9 problem.  If/when
the upstream authors decide to generate the shared library, we can
withdraw the package.

Generating a second, patched package is not complicated.  Indeed, here is
a first try (made from scratch using cdbs):

    http://people.debian.org/~rafael/glpk-shlib
    
The libglpk0 package is very slim and contains only the following files:

/usr/share/doc/libglpk0/
/usr/share/doc/libglpk0/README.Debian
/usr/share/doc/libglpk0/copyright
/usr/share/doc/libglpk0/changelog.gz
/usr/share/doc/libglpk0/changelog.Debian.gz
/usr/share/lintian/overrides/libglpk0
/usr/lib/libglpk.so.0.0.0
/usr/lib/libglpk.la
/usr/lib/libglpk.so.0 -> libglpk.so.0.0.0
/usr/lib/libglpk.so -> libglpk.so.0.0.0

This package does not conflict with glpk.  With both packages installed,
octave2.9 will find the header files (in glpk) at compile time and the
libglpk.so.0 shared library (in libglpk0) at link time.

What do you think?  Should we go ahead with this?

-- 
Rafael