[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