Hi Andreas. Your patch was almost right, but you forgot to set cadxcore (main library) dirs. A small patch is required for system to start up with new paths however, so plugin paths are hardcoded and visualizator plugin is required for visualization. I also renamed the exe as "ginkgocadx" to be more compliant with lib and share subdirs names. If you agree... this patch would be commited to be present in next release. If not partial or fully, we'll be pleased to modify anything you could propose. Hope it may be helpful. El 02/05/2011, a las 11:47, Andreas Tille escribió: > Hi, > > I'm moving a previosely private discussion to Debian Med list with the > agreement of the participants. Thus the longish quotes. Some comments > of mine as usual inline. > > On Mon, May 02, 2011 at 11:04:48AM +0200, Carlos Barrales wrote: >> Hi Andreas, >> >> >> On Mon, May 2, 2011 at 10:24 AM, Andreas Tille <andreas@an3as.eu> wrote: >> >>> I just downloaded the latest version 2.4.1.1 and had a look into its >>> packaging. Thanks to Carlos who tried to provide Debian packaging stuff >>> as well. However, we should try to avoid duplication of work here. We >>> just have such code at >>> >>> svn://svn.debian.org/svn/debian-med/trunk/packages/ginkgocadx/trunk/ >>> >>> (I just merged some differences) and IMHO it would be the best idea if >>> Carlos would commit directly to this repository (if prefered we can also >>> move it to Git). The way we handle the repository (SVN and Git) is >>> described in the Debian Med policy[1]. Carlos, please tell me whether >>> you like this idea and I can give further hints to give you a smooth >>> kickstart into this. In any it is not a good idea to store debian/ >>> directories in upstream source tarballs. The reasons are various and >>> discussed to dead on Debian lists. So please if you do your next point >>> release leave out the debian/ dir and try to communicate changes to it >>> via other channels to the Debian people (preferably straight to the >>> SVN). >>> >> >> I know about storing debian/. I only did it as a proof on concept for not >> uploading many src packages. >> Will remove that. > > Fine. > >> We have planned formally to use subversion git repository. Thank you for the >> offer anyway. > > To make sure that this is no missunderstanding: When we use SVN we only > keep the debian/ dir in the repository (not your code) so we simply keep > here what I asked you to remove from your sources. The policy for git > is a bit different - here people decided to maintain a clone of upstream > source plus the debian/ directory. In Git you clone your repository > anyway so this is actually no real "offer" of just another repository > but rather a suggestion to join the Debian Med workflow to simplify > things. > >>> I basically added some missing Build-Depends and did some other >>> polishing of the packaging. I can confirm that the build process works >>> somehow however the files will be installed into /usr/share which is >>> wrong for architecture dependant code. I tried to patch those >>> CMakeLists.txt files which contain the string share/ginkgocadx/bin >>> but cmake is somehow stubborn and continues to use this directory for >>> moving files into it and only in the final linking step it is seeking >>> the library in /usr/lib (where it does not exist). So I dropped my >>> naive patches (I'm not comfortable with cmake) and just would like to >>> ask you to follow FHS in installing which basically says: >>> >>> Binaries that should be user executable should go to /usr/bin >>> Architecture dependant files (like *.so) should go to /usr/lib/<pkg> >>> Architecture independant files (like *.mo) should go to /usr/share/<pkg> >>> >> >> CMake stores this location as vars. I noted that changing any of them and >> bulding with debian/rules it didn't update. >> In manual procedure (cmake .. [...]; make install) those updates works as >> expected, but when problem persist in cmake, a complete rebuild is >> recommended. >> Instead of that, your patches should work building and launching ginkgo, but >> you were unable to load visualization extension (see below). >> >> We know about the package location policy. I set that location because >> Ginkgo deployment was thought to be as a bundle. >> For that, plugins and translation locations are hard-coded to be relative to >> executable path, as you can see in the result. >> It's trivial to solve that. we will fix that to be dependant on CUSTOM_BUILD >> cmake variable in the next initial repository import. > > I commied my try as quilt patch to the Debian packaging but disabled it > in the series file because it does not result in a Debian package (there > is some linker error). Any cmake experts to make this working? > > Kind regards > > Andreas. -- Carlos Barrales Ruiz. MetaEmotion Healthcare. carlos.barrales@metaemotion.com http://healthcare.metaemotion.com/
Attachment:
debian-policy-patch.diff
Description: Binary data