Re: qrupdate - advice sought

[Jaroslav Hajek]

On Fri, Jan 9, 2009 at 1:00 PM, Søren Hauberg <address@hidden> wrote:
> fre, 09 01 2009 kl. 12:40 +0100, skrev Jaroslav Hajek:
>> I would like Octave to take advantage of these improvements.
>> Subsequently, I want to use them to further improve fsolve, lsqnonneg,
>> and possibly (in less immediate future) implement other optimization
>> routines that can benefit.
>>
>> Now, what is the best way to proceed?
>>
>> 1. Refresh and keep maintaining a copy of qrupdate under libcruft/ in Octave.
>> 2. Remove libcruft/qrupdate and require qrupdate to be linked.
>>
>> 1 is simpler. If we strive to get rid of some or all of libcruft
>> eventually, then maybe 2 is better, but it will make another (weak)
>> dependency.
>
> The problem with a library such as qrupdate is that no distributions are
> packing it at the moment. So, I'd say put it in libcruft for now, and
> remove it once distributions start packing it. Of course if nobody is
> packing it in a year, then I think we should remove it from libcruft to
> force distributions into packing it.
>
> Søren
>

This is a somewhat self-defeating solution: if we leave it in
libcruft, no package maintainer is probably going to notice anything,
so it will undoubtedly come to your second premise.
If we make it a dependency, most of them will notice the configure
message, think "WTF? another library?" and (hopefully) find it on
sourceforge. IMHO turning it into a package should be a POC, though
I've got no experience
there.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz