On Oct 20, 2006, at 10:39 , Pere Urbón-Bayes wrote:
>
> kaimmello wrote:
[snip]
>> - by having more than one version of the same component, for example
>> one stand-alone and one included in SAGE, we risk to betray the
>> spirit
>> of the free software, i.e. to use the available pieces of software.
I've not heard of that aspect to the Spirit Of Free Software (not
that I want to start a discussion on the subject).
>> Doesn't it recall the "Hell of DLL's" in Windows world?? SAGE has
>> been
>> up to now the best "glue" for the scientific software...IMHO it would
>> be really nice to glue also all existing debian packages.
My understanding of "DLL Hell" is the opposite: program A depends on
foo.dll (v. 1.4.1); your system has foo.dll (v. X). This means that
A's use of foo.dll has to match exactly what is available in v. X,
which, if X != 1.4.1, is where the Hell originates (APIs, bug-
compatibility, ...)
> I'm agree with the 90% of your comments, but the last one will be
> strange. The main problems is related with debian policy's that gave
> packages a better quality with QA phase, etc .. and this give them
> with
> some older packages. I think that we could no work this some debian
> packages directly, we have to look for some solution that help SAGE
> keep
> the correct software.
I can't speak to Debian packaging or policies, but for SAGE, today,
the assumption is that it comes with all it needs (other than a
compiler and related items). The issue is the DLL hell above (APIs,
bug-compatibility, ...).
> As i could remember the biggest problem could be related with
> python and
> pyrex, sage versions are patched with non-official solutions that
> never
> will be with debian ...
>> My hope would be to collaborate with the maintainers of the existing
>> packages in order to update them with SAGE requirements in mind.
>
> I think this is a good idea, but could be very difficult because there
> are debian guidelines that every package must agree. As i say'd the
> normal time to package something like SAGE is about two year to be
> agree
> with debian standards.
Do you mean "two years to get the first sanctioned package" or "two
years per update"? If you look at our history, updates come quickly.
In any case, I think users would probably just download the SAGE-ball
and hit the compile button. Within limits, it's pretty painless.
Being two years behind the 8-ball may not be a good position (not
knowing what lies beneath the Debian packaging/policy issues, I don't
know for example how whatever ends up being sanctioned will compare
with what's current).
> But how about other platforms, i think that could be interesting to
> form
> a sage packaging team that could do it for some platforms,isn'it?
I think it would be a great experiment to see what would be involved
in getting this to work. I don't know that this is something for The
SAGE Team to do.
Another wrinkle: if it takes a change to SAGE to permit Debian
packaging (or RPMs, or ...), it might not be something we'd want to
do. This is another reason the current strategy seems effective to me.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
Men are from Earth.
Women are from Earth.
Deal with it.
--------
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
