[Pkg-octave-devel] Re: Forking glpk

Falk Hueffner falk at debian.org
Tue Nov 15 21:22:35 UTC 2005


Rafael Laboissiere <rafael at debian.org> writes:

> [Cc to the maintainer of glpk.

Let me just point out I'm mostly only the uploader, the actual work is
done by Brady Hunsaker, whom I've cc'd.

> 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.

The difference is that the *ABI* changes frequently. It doesn't for
most projects. The X11 ABI hasn't changed for like 12 years, although
quite a lot of development has happened.

>> 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.
> [...]
>
> 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.

This will break horribly if the headers become out of sync with the
library. You absolutely need to provide matching headers.

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

I'm not really convinced. The problem is that you'll need a new
package name each time you upgrade, and this will leave lots of stale
library packages behind and generally be a hassle. If the goal is only
to provide a solution for octave, it would probably be easier to just
add a copy of glpk's source into the octave tarball and install it as
glpk-octave or something.

-- 
	Falk



More information about the Pkg-octave-devel mailing list