Re: Bug#731211: aster: new upstream release, work in progress
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
Reply to: