Hello André, On Thu, 2010-06-24 at 15:58 +0200, Andre Espaze wrote: > Package: salome > Version: 5.1.3-10 > Severity: wishlist > > Last week, Nicolas Chauvat, Sylvestre Ledru, Christophe Trophime and > I met some of the Salome upstream developers in Paris (at Logilab). > We presented the current patches [1] on Salomé 5.1.3 for upstream > inclusion. They are not going to be accepted for this release however most > of them have certainly good chances if they get ported to the upcoming > Salomé 5.1.4.
I'm sorry to hear that the patches will not get into 5.1.4, but I am glad that they are open to accepting our patches. > We were invited to try by using the up-to-date version > [2]. I have started to have a look on the main modules, KERNEL, GUI, > GEOM, MED, SMESH and VISU and it seems that most of the patches are > still relevant even if they need to be updated. Thank you for looking into this! It will be very helpful to have some working patches when 5.1.4 is released, so there is less work for us to do to get the package working. > However two important maintenance points should be considered when > porting actual patches to the future Salomé 5.1.4. The first is that the > '\*-build-in-tree.patch' family is very unlikely to be accepted. The > packaging process should instead configure, build and install each > module one by one like in the official way. Happily, this advice fits > also one of the Denis Barbier's suggestion for reducing the hard disk > space during Salome building by cleaning every module built directory > after its installation. Would the upstream request be an accelerator > for reorganizing the construction steps? Sure. I was planning on working on this within the next week, using Denis' patch as a starting point. As I've mentioned before, though it took a lot of work, this was the patch set that I thought upstream was least likely to accept, so this is no big surprise. > The second issue is the Debian constraint to build Salome with a HDF5 > library needing MPI. The corresponding patches (kernel-hdf5-needs-mpi.patch, > kernel-mpi-includes.patch, kernel-mpi-libs.patch and so on) are > not so welcomed by upstream. Really? Did they give an indication of why? Well, that's a relatively small patch for us to maintain. > Hopefully an alternative way of using > HDF5 may be provided as suggested by Sylvestre: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576004 Thanks. Unfortunately, the HDF5 group tends to take a long time to respond to such requests (often many months, even when a patch is available), so we shouldn't count on this to happen before our next upload. > In conclusion what could be the organization for welcoming the future > Salome 5.1.4 release? Should it be progressively ported on a separate > branch by using the up-to-date sources [2]? Or would you prefer a one-shot > transition from 5.1.3? If upstream is not going to accept patches before 5.1.4, then I think the one-shot transition makes the most sense. But I appreciate your examination of the upstream git repository to determine in advance what changes we will need to make in order to port our patches to 5.1.4. > In order to ease the upstream acceptance, I plan > to write a small report in French for explaining every patch purpose > (for the 5.1.3 version, I already did one for KERNEL and GUI modules > but its delivery is finally delayed). Sounds good, thanks! > [1] Found in debian/patches of > http://git.debian.org/git/debian-science/packages/salome.git > [2] The sources can be obtained with git > http://git.salome-platform.org/gitweb/ -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
