Hi, Andrea Palazzi a écrit :
So, the package is good, the only thing that should be changed, if we want to upload the package as soon as possible, is that with this packaging, code-aster-mpi-engine should depend on code-aster and not vice-versa.
I don't understand why we'd want this. With the current binary layout, code-aster (the Python library and elements catalog) cannot be used without an engine (the aster binary), whereas the engine could (in theory) be used without the code-aster Python library or elements catalog (although it wouldn't be more useful than a python interpreter).
On the other hand, I think that the packaging scheme should stay as it was previously: the code-aster package was originally meant to be a meta-package, just to allow to easlily install the whole thing with apt-get install code-aster; I think we should still follow this concept.
Even if it's not a meta package anymore, the code-aster binary package still provides this feature.
So, move all arch-independent files (mostly python) in another package, like code-aster-common; move the elements file and other arch-dependant files common to the serial and parallel version to another package code-aster-elements, and leave the code-aster package as a metapackage. Suggestions on better package scheme ( and naming ) naming are welcome :)
I think this is over-design. Let's keep it simple, unless there's a real need to have something more complicated.
Other issues/enhancements/wishes: - the code-aster package creates both /usr/lib/aster an /usr/lib/codeaster; the latter seems to be used just for a symlink from ../../share/aster . It's just a leftover of the old packaging, or CA looks for files in this path? Note however that code-aster-run puts some files under /usr/lib/codeaster, so we shoult ideally take also care of code-aster-run and code-aster-gui packages.
This symlink is precisely here so that as_run (from code-aster-run package) can still be used when aster is installed in /usr/lib/aster (not /usr/lib/codeaster). Ultimately, astk's packaging should be updated in order not to need this, but I currently I no time to do this.
- In the process, I'd like also to switch from svn to git.
Not sure I get your point. It's already done.
- as_run doesn't work out of the box: it relies on having informations about available versions in the file /etc/codeaster/aster ; the script update-codeaster-engines takes care of this, it should be run on postinst/postrm scripts of the code-aster-*-engine packages.
What does not work? AFAICT, it works: I can run 'as_run xxx.export' or some tests like 'as_run --test mtlp100a'.
- provide also the serial version - a simple script to run the test cases would be nice... the .comm file that was used for this purpose has been removed from upstream, or it's just me that can't find it?
- we should fix libmetis in one way or another, either by adapting the sources to libmetis 5.1.0 (the metis documentation says something about this process) or by changing the default renumerator from METIS to something other, like MD, so that it can be compatible with comm files that doesn't specify the renumerator to be used.
The tree latter points would be nice, indeed.
- 11.5 is already out
And I updated the packaging for this version already.
- and I'd like to provide also testing/unstable versions
Again, let's keep it simple first. Regards, Denis -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5332987f.5040...@laxalde.org