Hi Andreas, I agree with you that forking the project is a bad idea. I'll tell Seg3D maintainers that I step back from packaging it, at least until we can think of a good way to handle the dependencies.
It's a pity, because I still think that Seg3d is a nice software and a much needed one to easy create segmentations. I'll concentrate next on itksnap instead (http://www.itksnap.org/pmwiki/pmwiki.php) and look at debian's patches once more :) Thanks for the kind response, Best, Mario PS: Should you get in touch with Seg3d maintainers and they be willing to change their policy, please tell me so I can resume packaging. PPS: If anyone is curious, Fedora's package guidelines are available here ( http://fedoraproject.org/wiki/Packaging:Guidelines) On 23 May 2013 17:34, Andreas Tille <[email protected]> wrote: > [Debian Med list in CC for further wisdom hints] > > Hi Mario, > > (I guess I should have read this before I have written my previous > answer.) As a general answer there exists a so called Upstream Guide > in the Wiki > > http://wiki.debian.org/UpstreamGuide > > IMHO everything written there should also apply for Fedora. I'm > personally astonished that the topic of bundled libraries is not (yet) > mentioned there. I'll suggest the authors of this guide to include this > topic. > > On Wed, May 22, 2013 at 01:15:33PM +0200, Mario Ceresa wrote: > > Dear all, > > I had an interesting talk with Seg3D mantainers on the possibility to > > accept patches to build against system version of the many bundled libs. > > However, as you can see from the forwarded mails, they seem not willing > to > > help with that nor to accept any related patches. I'm not sure what to do > > here: shall I package it regardless? I fear I'll end up mantaining a fork > > of the program... > > > > What would you suggest here? > > I admit that's a pretty bad situation. We just have some packages where > upstream includes third party software and we were not lucky enough to > convince them about droping it (even if constantly talking to them for > every new version). However, I do not remember any case where really > widely used, large projects like boost or itk are affected by this > problem. That's really bad and I admit I do not have a reasonable > answer to this. For the moment I would regard this as a show stopper > and move to another package on your list. > > I personally would not consider to maintain a clean fork if this is more > than say up to ten easily maintainable / automatically generatable > patches. Finally your version will be way less tested and once users > might learn that "the Fedora packages of medical imaging are broken" > (yes, they might do this generalisation even if this is not true) this > might affect your whole project. > > We might like to do another try from Debian Med side. Perhaps upstream > might start thinking about it if two major distributions will not > consider something that would be in their interest ... > > Kind regards > > Andreas. > > > ---------- Forwarded message ---------- > > From: Ayla Khan <[email protected]> > > Date: 22 May 2013 07:09 > > Subject: [Seg3D] Re: Packaging seg3d for Fedora - Problem with > > boost::mutex > > To: [email protected] > > > > > > Hi Mario, > > > > Many of the libraries we include with Seg3D have been modified, even if > the > > modifications are as basic as replacing their default builds with CMake > and > > doing some symbol mangling to make libraries play well with ITK. Our > Boost > > distribution includes a project from the Boost sandbox that will not be > > available in a generic distribution. ITK has been customized as well. > > > > Including specific versions of third-party libraries allows us to > maintain > > stable Seg3D builds across multiple platforms (Windows, Mac OSX and > > different Linux distributions) with the least amount of effort for SCI > > developers. We are also tightly coupled to Boost, ITK and Teem, so it is > > preferable from our point of view to build against versions that we > control. > > > > Having a binary distribution for Fedora would be helpful - it's certainly > > been a good thing for our Windows and OS X users, however keeping our > > dependencies uniform across supported platforms has eliminated many of > the > > deployment headaches we used to have in the past. > > > > Ayla > > > > On May 7, 2013, at 3:27 AM, Mario Ceresa wrote: > > > > > Thanks Dan and Ayla for your prompt response! When do you plan to > release > > 2.1.5? > > > > > > As for the 3rd party libs, unfortunately, Fedora has a strict policy > > > of not bundled and not static libs: > > > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries > > > > > > https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries > > > > > > The only exceptions granted are usually for libraries that are heavily > > > modified. Does any of the 3rd party libs in "external" meet this? > > > > > > Including seg3d in a distribution like Fedora it is usually a positive > > > force: it means a large user base, continuous feedback, builds ready > > > available for x86, arm and ppc archs, access to last releases of all > > > libs, prompt bug reports and many submitted patches. It also relieves > > > you part of the burden to assist users with bugs: package maintainers > > > will usually catch them up early and report to you, sometimes along > > > with a proposed fix. Thus you can concentrate more on working on your > > > software instead of all the maintenance tasks. > > > > > > You can think about it as an investment :). > > > > > > However, it needs a bit of involvement by your side because I cannot > > > maintain a complete fork of seg3d. > > > > > > In the end I don't think the process is so complicated: we just need > > > to ensure we can choose at build time whether to link seg3d with the > > > included static libs or against system wide ones. I can send a patch > > > for this, if you are willing to review it. Then, if any > > > bugs/regression arises, we will work towards a fix. > > > > > > I do hope that this would be the beginning of a long joint > collaboration! > > > > > > With best regards, > > > > > > Mario > > > > > > > > > > > > > > > > > > > > > > > > On 7 May 2013 07:07, Ayla Khan <[email protected]> wrote: > > >> Hi Mario, > > >> > > >> You should check out the 2.1.5 release branch ( > > https://code.sci.utah.edu/svn/seg3d2/branches/2.1.5), or wait until I > merge > > the updates from the 2.1.5 release candidate back to the trunk once the > > release is done. We're currently targeting a modified Boost 1.53.0 > library > > (see the Modifications.txt file in the src/Externals/boost directory). > Keep > > in mind that Seg3D is designed to work with statically linked libraries > > built from the third-party dependencies that we include with it's sources > > and does not support the use of other versions. I would strongly > recommend > > using our libraries and then attempting to work with Fedora's Qt system > > libraries. > > >> > > >> Ayla > > >> > > >> > > >> On May 6, 2013, at 12:42 PM, Dan White wrote: > > >> > > >>> Here is the fix for that error from our svn branch. Ayla can provide > > more info, since it looks like there were multiple boost-upgrade-related > > Seg3d2 source compiler fixes in addition to this one. > > >>> > > >>> > > > https://gforge.sci.utah.edu/gf/project/seg3d2/scmsvn/?action=browse&path=%2F&view=rev&root=seg3d2&revision=1834 > > >>> > > >>> > > >>> On 5/6/2013 5:44 AM, Mario Ceresa wrote: > > >>>> Hi all, > > >>>> first of all, thank you for your work on seg3d: it's really a nice > > >>>> software and helps a lot for image segmentation! > > >>>> > > >>>> I would like to package it for fedora, however, I have several build > > >>>> problems. Once is especially difficult for me to figure out and I'd > > >>>> appreciate some help. > > >>>> > > >>>> I have a: > > >>>> * no matching function for call to > > >>>> > > > ‘boost::shared_lock<boost::shared_mutex>::swap(Core::MaskDataBlock::shared_lock_type) > > >>>> > > >>>> in Application/Filters/Actions/ActionAndFilter.cc:149. I past the > full > > >>>> compiler error: > > >>>> * http://ur1.ca/dpo7o > > >>>> > > >>>> You can find in github a fork of the code with some of the changes > so > > far: > > >>>> * https://github.com/mrceresa/seg3d2 > > >>>> > > >>>> They are almost only in the cmake build system to enable use of > Fedora > > >>>> system-wide libs such as: > > >>>> > > >>>> * boost 1.50 > > >>>> * gdcm 2.0.18 > > >>>> * ITK 4.3.1 > > >>>> > > >>>> Which is required for packaging. > > >>>> > > >>>> This was the cmake build line: > > >>>> ccmake ../seg3d2 -DCMAKE_CXX_FLAGS="-fpermissive" > > >>>> -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_WITH_PYTHON=OFF > > >>>> > > >>>> Thanks for your attention and best regards, > > >>>> > > >>>> Mario Ceresa > > >>> > > >> > > > _______________________________________________ > > Medical-sig mailing list > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/medical-sig > > > -- > http://fam-tille.de > _______________________________________________ > Medical-sig mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/medical-sig >
