Re: [MoM] Packaging mindthemap (Was: Request to contribute to DebianMed and be part of MoM)
Hi Shayan and Andrius,
On Wed, Jul 03, 2019 at 03:11:04PM +0300, merkys@debian.org wrote:
> On 2019-07-03 15:02, hello@shayandoust.me wrote:
> > Is this where I now have to rely on the pre-built gatb-core package that already exists within sid and testing as a build dependency by editing the rules and control file instead of going down this route?
>
> Yes. Ideally, mindthegap should use system-provided (Debian packaged)
> gatb-core to build.
>
> > I was thinking of quilt patching but I don't think that's the way to do it.
>
> This is usually the only way. Some CMakefiles are able to detect
> system-provided libraries, however, sometimes one has to patch them.
Fully ACK here. Since learning by example is probably the easiest way
I'll provide you with one that will make things clear hopefully. How to
find the example?
$ apt-cache rdepends libgatbcore2
libgatbcore2
Reverse Depends:
minia
libgatbcore-dev
discosnp
Libgatbcore-dev is obviosly from the gatb-core source package and thus
does not help much here. So what about discosnp and minia? If you
check the quilt patches of discosnp you will find this one:
https://salsa.debian.org/med-team/discosnp/blob/master/debian/patches/use_debian_packaged_gatb-core.patch
So what you need to do is
quilt new use_debian_packaged_gatb-core.patch
quilt edit CMakeLists.txt
do the changes that are needed to use the Debian packaged gatb-core
quilt refresh
quilt pop
For sure you also need a
Build-Depends: libgatbcore-dev
in debian/control to make sure this library will be available in your
pbuilder chroot at build time.
For sure it make sense to check minia as well in case the CMakeLists.txt
comes closer to your own target. I hope with these two examples you
will manage to build against the Debian packaged gatb-core and you are
convinced that the Git submodule code is not needed.
Attention: When I was packaging minia and discosnp I realised that one
of these (I do not remember which one) needed a later development state
of gatb-core than the other one. I solved this in a really wimpy way:
Just by try and error which commit would fit both. I blame gatb-core
upstream for not doing a proper release management and providing a
stable ABI for the dependant software. So you might realise that the
gatb-core code that is needed for mindthegap might be even newer than
the existing one in the Debian packaged gatb-core lib. Here we have a
real conflict between Debian policy to avoid code duplication inside
Debian and the more and more frequent usage of simply throwing any
commit as submodule in some code and may be trust Conda or other
packaging systems to fetch whatever fits (any security implications left
aside by this method).
Disclaimer: I have not checked the current situation with gatb-core but
simply described the situation at least half a year ago. May be
upstream has started now a stable ABI and is doing proper release
management! You might like to verify this possibly.
For your current packaging this means:
A. Current Debian packaged gatb-core is working with mindthegap
-> Fine
B. In case you get build errors with strings that might be part
of gatb-core check we need to upgrade gatb-core to a commit
that works - may be the latest or the one that was used as
submodule. However, before we continue we need to make sure
that minia and discosnp will continue to build and run with
this new gatb-core version. And we need to bump the SOVERSION
we invented inside Debian to create a proper versioned dependency
relation.
This is in detail what I said in short in one of my initial mails for
your packaging attempt of mindthegap.
Hope this helps
Andreas.
--
http://fam-tille.de
Reply to: