RFC: Rethink Code Aster build/deployment practices

kwah · 2009-08-06 13:26:11

-- Current state --

Currently, Code_Aster available as a package of "sources" (aster-full-src-$VERSION.noarch.tar.gz). This package in-fact contains a number of components in various state with various licenses and in-house build/install system.

There are nineteen (19) .tar.gz tarballs within distributed tarball (aster-full-src-10.0.3-2.noarch.tar.gz), of which:
* gmsh, grace, hdf5, med, Numeric, omniORB, omniORBpy, tcl, tk, scotch are available in recent distributions
* metis-edf (metis with some EDF applied patches), which is similar to parmetis, and to scotch, which are also available in distributions
* mumps - package available for e.g. Debian/unstable [1]

This leaves a number of unique (only 7) components distributed with Code_Aster:
* astk - a client-server front-end for the Code_Aster finite element software (a.k.a. aster), as well as a build system used by Code_Aster and Homard [2]
* aster - Finite Element Analysis (FEA) software for engineering simulations [3]
* gibi - (?), which is non-free (no sources available. license unknown)
* eficas - ASter Command FIle Editor [4]
* eficas-doc - documentation for eficas [4]
* homard - The HOMARD software carries out the adaptation of 2D/3D finite element or finite volume meshes by refinement and unrefinement techniques. Non-free, no-sources, redistribution of binaries tied to Code_Aster
* pylotage - (?)

There is also a home-brewed build/install system (a set of python scripts), which is able to produce a locally deployable set of components on top of which Code_Aster may run.

-- Packaging attempts --

There was (is?) an attempt to produce packages suitable for deployment by Debian package management system for aster based on aster-full-src-9.2.0-2.noarch.tar.gz (see [1]-[4], especially [2]), which faced a number of challenges like:
* It doesn't look straightforward to disentangle the build system from the "server" component that runs the aster FEA binary, see [2]
* To perform packaging according to standards there was need to patch sources [2]-[4]
* Author was not able to get in touch with Code_Aster developers

At the same time there were other attempt in packaging [5], where the following was mentioned:
* All files are built out of regular build destination, which normally is under our Package-Version/debian directory, but Code_Aster installation mechanism is only made to be installed by hand, not to be packaged: you cant compile in one directory and use it in another (or we dont know how to)
* One package for many things. Debian (and Ubuntu) refused to package more than one thing (executable or library) in one package. To follow theses rules, Code_Aster must be split into many packages
* No file provided by this setup follow essential Filesystem Hierarchy Standard, which explains how to correctly install libraries, users executables, system executables, etc. (recall : /opt : Add-on application software packages, not huge tree to push unsorted things...)
* Package licensing is not correct either : it must provided separate license for each part of Code_Aster
* Many many many other things, but not all of them are related to development, as it has been said; even this packaging method doesnt follow the Debian packaging rules

-- Conclusions --

There is a number of advantages in use of available in distributions packaging mechanisms Code_Aster project may benefit from:
* Easy deployment/installation and wider audience aware of the tool and hence community of users/developers
* Availability of packaged software and package management system dependency tracking, and hence no need to ship in one bundle all currently provided "source"-packages and build/install-system
* No need to support/extend in-house build/install system
* Reduced number of components to be maintained/deployed (from 19 to 7?)

Therefore, it would be nice, if Code_Aster developers gave their opinion/view on possible further developments with respect to deployment of the software by the distributions and via distribution's software repositories, which, as it is clear from remarks above, requires reorganization of build/deployment process, as well as on possible involvement in the project of other people (building community?) like maintainers, documentation writers/translators, developers etc.

Thank you in advance.

[1] MUMPS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491024
[2] astk http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467085
[3] aster http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458812
[4] eficas + doc http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467097
[5] http://www.code-aster.org/wiki/doku.php … n_packages

kwah · 2009-08-14 11:40:13

Either this is the wrong place to ask or developers do not really interested in other ways of distribution.

Is there somewhere developers forum/mailing list, where discussion on the topic may be held?

Thanks.

delmas · 2009-08-14 13:30:58

Dear Kwah,

Your post is very interesting and you're right on a lot of points.
A lot of Code_Aster devoloppers are on holidays, then you have to wait september to have an appropriate answer on that very important topic.

Regards.

kwah · 2009-08-14 23:00:03

Dear delmas,

Thanks for your kind reply. Hope to hear from the developers.

Cheers.

mathieu.courtois · 2009-09-01 14:04:21

Dear Alexey,

Of course you're right on the most of points.
I won't answer to all your questions now, it would be a bit long !

First you have to understand that as big as EDF is, EDF developpers can not spend a lot of time on the opensource distribution. Their main job is to answer to the needs of the engineering of the company.
(and so as there is few people who worked on the distribution I'm ok to be guilty !)

For the history, I provided rpm packages in 2002/2003 but I could'nt maintain them, build packages on all rpm-based distribution... That's why I choose to work on the "home-brewed build/install system".

Second, some of our prerequisites are EDF made but not by the Code_Aster team. So we can try to commit patches but not surely.

Then you speak about attempt of packaging where "author was not able to get in touch with Code_Aster developers". Sure that debian.org is right place to speak about packaging but none of us is a debian developer...
And we often spoke about Code_Aster packages on www.code-aster.org, even with volunteers, but there is a lot of work.
(there are not a lot of posts without answer in this forum)

Your other post about licensing is interesting : Code_Aster is GPL but this is right that aster-full is not. We must clarify this.

So as conclusion, if you have time to contribute, you're welcome ! We could list the tasks and see how to help ourself : you about packaging pratices, we about code-aster, including patches...

For example :
- I began to work on future version of astk/asrun which should be conformed to the LSF hierarchy. I have not 3 days to spend to understand LSF, so any advice will be appreciated. We could open a thread on that.
- I'm also working to build aster binaries from a Makefile, without using as_run (which stays necessary to help developers to add/test their modifications). This should help to build binary packages.

Hope this discussion will continue (I didn't answer to all points).
We could open threads on particular points and we will try to work on these as soon as possible (probably at night ).

MC

delmas · 2010-07-16 12:19:28

In which way do you want to contribute ?

apalazzi · 2010-10-19 08:05:34

petrovyoung wrote:

there are a significant number of pre-rquisite packages in Ubuntu repositories. I have not tried to compile Aster with system libraries on Ubuntu, but the last time I tried (it was on PCLinuxOs), I had severe difficulties: problems with incompatible compile options (-fPIC) and version mismatch creating runtime issues.
My biggest worries were with HDF5 and MED... two core libraries for Aster/Salome.
But I know that Ubuntu packages are much more up-to-date than what I could find on PCLinuxOS by that time, so it would be worth trying at least.

Hi,

Actually code-aster can be built with system libraries, except for MED and HDF5, that are causing runtime problems.
With the next update (10.2.21) it should be possible to also use med and hdf5 shipped from the system.

By the way, I found a pretty handy utility to create packages in a simple way: it is called "CheckInstall" and can create DEB or RPM packages from a single command line. For example Aster packages could be built in this way :
1) extract aster-src and create a few doc files + pre/post install scripts to be included in the package
2) build/install Aster and create package:
Code:
checkinstall setup.py

Does anybody have some experience with this tool?
..This could be worth trying at least... if it really works, it would be a clear step forward to simply build packages that are not following the classical configure/make/make install procedure.

I never used it... anyway the debian packaging of code-aster is on the way - see http://www.code-aster.org/forum2/viewtopic.php?id=14417.

Bye

Andrea

mathieu.courtois · 2010-10-19 19:50:17

No news about kwah... but you may have a look at http://www.code-aster.org/forum2/viewtopic.php?id=14417

MC

petrovlucca · 2010-10-31 03:02:20

Yep, I saw and read available info. And... Yep, there is package for MED, after you pointed it out, I found libmed
Code:

$ aptitude search libmed
p libmed-dev - Development files for libmed
p libmed-doc - Documentation for the MED-fichier library
p libmed-tools - Runtime tools to handle MED files
p libmed1 - Library to exchange meshed data (Fortran v
p libmedc-dev - Development files for libmedc
p libmedc1 - Library to exchange meshed data (C version

but a little outdated for Aster 10: v 2.3.1 is packaged. So, there is even less components that need actual initial packaging to have debian/ubuntu specific packages of Aster available

To the point of complex installers like Aster's setup.py: distribution package system should completely replace it, and give more possibilities like updates, for example. And I think that having such installer, although working really well!! , is really unnecessary.

Returning back to my message: may be you know how one may check that built MED library/tools work correctly?

-- Added 2009/08/04 around 20:10 UTC+1

There is (was?) some effort on having aster packaged for Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458812

-- Another addition

There was also a huge effort to package Salome 3.2 for Debian/unstable, which, unfortunately, was stalled by unresponsive upstream, see the following discussion: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457075

So, it looks like there is plenty of expertise in packaging OCC/Aster/Salome already out there, and it might be wise to take a look at work that has been done so far and build on top of it.

#1 2009-08-06 13:26:11

RFC: Rethink Code Aster build/deployment practices

#2 2009-08-14 11:40:13

Re: RFC: Rethink Code Aster build/deployment practices

#3 2009-08-14 13:30:58

Re: RFC: Rethink Code Aster build/deployment practices

#4 2009-08-14 23:00:03

Re: RFC: Rethink Code Aster build/deployment practices

#5 2009-09-01 14:04:21

Re: RFC: Rethink Code Aster build/deployment practices

#6 2010-07-16 12:19:28

Re: RFC: Rethink Code Aster build/deployment practices

#7 2010-10-19 08:05:34

Re: RFC: Rethink Code Aster build/deployment practices

#8 2010-10-19 19:50:17

Re: RFC: Rethink Code Aster build/deployment practices

#9 2010-10-31 03:02:20

Re: RFC: Rethink Code Aster build/deployment practices

Board footer