Rafael Laboissiere <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
