Bug#731211: aster: new upstream release, work in progress

[Denis Laxalde]

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