[Debian-med-packaging] CamiTK bug fixed(?)
Emmanuel Promayon
Emmanuel.Promayon at imag.fr
Fri Jan 11 15:10:39 UTC 2013
Dear Mathieu,
(I just continue in public as it is attached to the same thread/message)
>> I therefore modified the soname properties in the source tarball upstream
>
> Arghh ! Never change upstream source. Tag are supposed to be read-only
> (gpg signed...). This makes my life much more difficult (and may even
> confuse external contributors since upstream source and debian orig
> tarball wont match)
oups... I am still confused when to wear the "upstream" hat or "debian
packacing" hat. I will do more reading about it.
Should I revert the change upstream and add a patch?
Or is it better to include all the patches upstream (include the one you
added, see below), issue another version (3.0.4), and use dch -r?
>> and commented the lintian-override line (should I delete it now that it
>> seems to be only filled with comments?).
>
> Comment is very clear now, thanks.
>
>> I now have:
>> $ lintian camitk_3.0.3-1_amd64.changes
>> W: camitk source: newer-standards-version 3.9.4 (current is 3.9.3)
>> W: libcamitk3: package-name-doesnt-match-sonames libcamitkcore3
>> libmonitoring3 libqtpropertybrowser3
>
> I use `lintian -E -o -I` generally
Thanks for the tip.
>> 2) I moved the source of the specific plugin that was based on tetgen out of
>> the camitk source tarball. What would be the best way to generate a new
>> package, i.e. libcamitk3-extra-non-free?
>
> Why not `libcamitk3-tetgen-plugin`. I do not see the point in having
> extra or non-free in the name. Do you have a tetgen and
> tetgen-non-free package ?
Ok I get the point. libcamitk3-tetgen-plugin or
libcamitk3-tetgen-extension (as "extension" is what camitk calls its
plugins) is perfect.
I will look into the generation of this extension.
> As a side note, I fixed an issue with SONAME and plugins:
>
> (around line 45):
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/camitk/trunk/debian/patches/sonamefix.patch?view=markup
>
> However this now confuse cmake, during linking. It cannot use the
> SONAME anymore on the link line. I am sure there is a way to fix this,
> I just cant remember from the top of my head. Either ask on the
> mailing on how best to link two plugins (no SONAME), or read the cmake
> documentation :)
>
> Feel free to edit in place the patch, once the issue goes away (use
> readelf -d to check the NEEDED section does not start with
> `../../bin/components`). Package should be ready to go then.
>
> Thanks !
>
Thanks for your patch (including the proof-reading). I am going to look
into that quickly.
Best regards,
Mahnu
More information about the Debian-med-packaging
mailing list