scid deb packages

[jordisayol]

scid deb packages available on:

https://code.google.com/p/d-apt/wiki/APT_Repository#APT_Repository_for_D

"d-apt" is an ATP repository to easily install/upgrade D binary packages on systems like Debian, Ubuntu, Linuxmint, etc.

Enjoy it!

[kyllingstad]

This is great! :-) Do you have some way of keeping the packages up-to-date with the repositories, or are you doing this manually? (In the latter case I'll try to remember to notify you if I make any substantial changes to the library.)

[jordisayol]

Thanks a lot for your comment! By the moment all packages are 50% script compiling and 50% manually build. The idea is to rebuild all of them every dmd release, but if there is a substantial library change, of course I'll create a new deb package, just let me know. BTW, until now, nobody has download most of them :-/ https://code.google.com/p/d-apt/downloads/list This is not new for me, I'm packaging gtkd library for a while and I know how hard is to do this just for about 5 people in the beginning (downloads in about two months), and now is about 70 downloads. If you like it, please don't hesitate to make advertising. Thanks!

[kyllingstad]

I have linked to d-apt from the wiki page now (both as a news item and in the "installation" section).

I've taken a look at the deb package, and I have two suggestions to make. Neither requires recompilation, just a metadata update.

• The package should depend on liblapack-dev.
• It would be nice if you could use the URL to the wiki page as the home page instead, both in the package and on the d-apt page. The address is: https://github.com/kyllingstad/scid/wiki

Thanks again for doing this! :-)

[kyllingstad]

BTW, I pushed an update a few minutes ago (kyllingstad@e3c116ccf965b65a120741c6477ca3956f4cb2c6), but it's not something you need to worry about. It's just some minor changes to the build script, which you have obviously managed without. ;-)

[jordisayol]

Ok, I've updated all links on deb packages to scid wiki URL Will be visible on next release.

About package dependencies, I've to explain you something. All the deb packages I've built until now, includes both 32-bit and 64-bit static libraries, so a project including i.e. plot2kill library, can be compiled to 32-bit and 64-bit, without care on bit system host. i.e. in a debian 32-bit you can compile this:

$ dmd `pkg-config --cflags --libs plot2kill gtkd` -m64 my_plot2kill_app.d

and you'll get a 64-bit executable. Of course it cannot be run on this system, but in a Linux 64-bit.

Plot2kill and gtkd libraries do not have external dependencies at compile time. This is not the scid case, which depends on liblapack-dev, libblas-dev and gfortran. This mean that can be compiled only to the bit system host, because the dependencies are only available for this bit. To avoid this limitation I've included all these three static libraries into the libscid.a one. Doing like this, I can include both 32-bit and 64-bit libraries without any external dependency broken. This make possible to compile scid programs in this way without care on bit system host:

$ dmd `pkg-config --cflags --libs scid` -m32/64 my_scid_app.d

But this also make the libscid.a size increase a lot compared if it hasn't them.

If you don't like this solution or know a better way to do this, please let me know.

[jordisayol]

BTW, many thanks to you too to include the apt link on scid wiki

[kyllingstad]

If you don't like this solution or know a better way to do this, please let me know.

I don't have a problem with this solution, although I do think it should be clearly stated in the package description. It may not be what everyone wants.

[jordisayol]

I'm agree with you in to clearly state in the package description, but I'm not so happy with this solution, in fact, I'm thinking to change this policy and make all packages containing only the platform library. This imply to allow compiling to the bit host system only.

What do you think about?

[jordisayol]

OK, I'll build packages to both 32-bit and 64-bit if the library has not external dependencies, and only with a library for the host architecture if it has some external dependency. By the moment, scid is the only one in this situation. I've uploaded a new version of scid deb packages, with dependencies on liblapack-dev ,libblas-dev and gfortran.

There are also available separated packages for documentation, like libscid-doc. It add a link with icon on Linux menus. If you don't like the icon, please let me know.

Any comment and testing are welcome.

[jordisayol]

Recently, d-apt has moved to http://d-apt.sourceforge.net/. Due to new shared libraries, I've split d-apt deb packages:

libscid-64_0~2013.08.03-0_amd64.deb (shared library for run-time) libscid-64_0~2013.08.03-0_i386.deb libscid-dev_0~2013.08.03-0_amd64.deb (static library, etc. for compile time ) libscid-dev_0~2013.08.03-0_i386.deb libscid-doc_0~2013.08.03-0_all.deb (documentation in html)

I've some doubts about dependencies on gfortran. Is it just necessary to compile the libraries? or when generating programs linked against scid? or is also needed at run-time?

[kyllingstad]

SciD doesn't call any functions from libgfortran directly; it only calls LAPACK and BLAS functions, so I actually think those should be the only dependencies. Any dependencies on libgfortran (and gfortran, if necessary) should be indirectly handled through them.

Note that there are several different BLAS and LAPACK implementations, and the user should be able to choose between any of those. It looks like the way other packages do this is to make the packages depend on libblas3|libblas.so.3|libatlas3-base and liblapack3|liblapack.so.3|libatlas3-base.

[jordisayol]

Ok, then I'll make shared deb and static deb packages depend both on libblas3 | libatlas3-base and liblapack3 | libatlas3-base

libblas.so.3 and liblapack.so.3 are not present as available deb packages on Debian systems.

BTW If you include some basic tests on your project, I'll include them on the doc package.

[jordisayol]

Sorry, libblas.so.3 and liblapack.so.3 are the virtual packages provided by all them. I'll include dependencies as you said.

[kyllingstad]

@jordisayol:

Ok, then I'll make shared deb and static deb packages depend both on libblas3 | libatlas3-base and liblapack3 | libatlas3-base

By "static deb", do you mean the libscid-dev package? Looking at other packages in the Debian repositories, it looks to me like libscid-dev should depend on libblas-dev, liblapack-dev and libscid, while libscid should depend on the packages I mentioned earlier.

[jordisayol]

"libscid-64" - includes the shared "scid" library for run-time purposes. "libscid-dev" - includes static "scid" library, module sources, symlink to shared "scid" library and pkg-config files.

"libscid-dev" depends on "libscid-64". If "scid" needs to link against "libblas" or "liblapack" during compilation, then "scid-dev" should depends on "libblas-dev" and "liblapack-dev" deb packages. Otherwise, if "scid" only needs them at run-time, then these dependencies are not necessary. Please tell me what's the case here.

Note: I've included the dmd version number i.e. "64" on shared deb name because every dmd release breaks API and ABI. This will be removed as soon as dmd becomes stable.

[kyllingstad]

No, you're right, it doesn't strictly need them. It shouldn't be a problem to use the static SciD library with dynamic LAPACK and BLAS libs. You only need static versions of the latter if you explicitly want to statically link all libraries into the executable. I just thought it was common for -dev packages to depend on other -dev packages when the libraries themselves are functionally dependent. But you probably know a lot more about this than I do.

[jordisayol]

If "scid" can statically link to "blas" and "lapack" libraries, then their -dev packages should be included as scid-dev dependencies.

[jordisayol]

I'll add libblas.so | libblas-dev | libatlas-base-dev, liblapack-3.so | liblapack-dev | libatlas-base-dev as scid-dev dependencies, allowing static linking. Thanks!

Some examples will help to test them.

[kyllingstad]

Apart from the unittests, you mean?

[jordisayol]

That's right ;-)

[jordisayol]

btw, d-apt server has been moved to http://d-apt.sourceforge.net/

[kyllingstad]

I will try to find time to add some examples. As you can see, I have created a new issue for this, and I'll close this one for now.

Anyway, thank you, @jordisayol, for the work you're putting into maintaining the D-APT repository. I am one of your users, and I really appreciate the convenience of having the D toolchain easily available through apt-get. :-)

[jordisayol]

Thank you very much :-)