Hi, I adopted the scipy package in debian, it will be fixed soon. And definitely I'll be available to test the new release so that it works in Debian. In the process of polishing the package I noticed there are sources of SuperLU included, but not of the umfpack. I think either there should be both sources of superlu and umfpack, or nothing. I personally am for nothing, since they are already in Debian as separate packages, so it is better to link against already installed packages - saves space and it is the cleaner solution. Also if there are some bugs discovered and fixed by upstream (superlu, umfpack) or the maintainer of the respective debian package, all I need is to recompile the scipy package, so I am using the work made by others (contrary to distributing the sources of superlu ourselves, in which case we need to fix everything). Ondrej
Ondrej Certik wrote:
Hi,
I adopted the scipy package in debian, it will be fixed soon. And definitely I'll be available to test the new release so that it works in Debian.
Thank you! That's wonderful news.
In the process of polishing the package I noticed there are sources of SuperLU included, but not of the umfpack. I think either there should be both sources of superlu and umfpack, or nothing.
UMFPACK is GPLed and optional (for that reason), so we cannot distribute it. SuperLU is under a BSDish license, is not optional, and is small enough to include that the costs of doing so are outweighed by the benefits of not forcing most scipy users to download and build SuperLU separately. We don't all use Debian.
I personally am for nothing, since they are already in Debian as separate packages, so it is better to link against already installed packages - saves space and it is the cleaner solution. Also if there are some bugs discovered and fixed by upstream (superlu, umfpack) or the maintainer of the respective debian package, all I need is to recompile the scipy package, so I am using the work made by others (contrary to distributing the sources of superlu ourselves, in which case we need to fix everything).
As a package maintainer, you are free to patch up scipy as you see fit in order to reuse other packages in your distribution. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
In the process of polishing the package I noticed there are sources of SuperLU included, but not of the umfpack. I think either there should be both sources of superlu and umfpack, or nothing.
UMFPACK is GPLed and optional (for that reason), so we cannot distribute it. SuperLU is under a BSDish license, is not optional, and is small enough to include that the costs of doing so are outweighed by the benefits of not forcing most scipy users to download and build SuperLU separately. We don't all use Debian.
I can see now - it makes sense to include SuperLU, so that at least one solver is working out of the box for every scipy user. Generally though, my philosophy is not to distribute other programs in projects, but rather it is the job of the linux distribution (whichever you use) to do so. OK, thanks for clarification. Ondrej
participants (2)
-
Ondrej Certik -
Robert Kern