Moving kompare build to dh sequencer and libpkgs_gen_strict_local_shlibs
Aurélien COUDERC
zecoucou at free.fr
Sun Jun 28 21:54:14 BST 2020
Hi,
thanks for your detailed feedback, that’s appreciated.
Le dimanche 28 juin 2020, 15:27:34 CEST Pino Toscano a écrit :
> Hi,
>
> In data giovedì 18 giugno 2020 00:17:41 CEST, Aurélien COUDERC ha scritto:
> > I’m working on updating kompare and would like to move the build to using
> > the dh sequencer.
> >
> > However the current d/rules uses this:
> > libpkgs_gen_strict_local_shlibs = $(libpkgs_all_packages)
> > include /usr/share/pkg-kde-tools/qt-kde-team/3/library-packages.mk
>
> This can stay.
>
> > Question is how can I reproduce this behaviour with pure dh ?
> > Any existing examples ?
>
> override_dh_gencontrol: libpkgs_gen_strict_local_shlibs
> dh_gencontrol
>
> Or restricted to only arch binaries, in case the source has both:
>
> override_dh_gencontrol-arch: libpkgs_gen_strict_local_shlibs
> dh_gencontrol -a
Will do thanks for the examples.
> In any case: when you find such setup, please keep it even without
> dhmk: having a strict dependencies between binaries of the same source
> avoids version mismatches that lead to issues in the past.
Yes, that’s precisely why I’m asking. :-)
> Strictly speaking, you can do this without this makefile snippet;
> however there are two downsides:
> - you have to copy&paste the strict dependencies in all the binaries
> - you hardcode the strict library dependencies, which means that if a
> binary either gains a dependency on another binary of the same source
> or it loses it, you have to update things manually; example:
Indeed, that second drawback was making me uncomfortable switching away from this,
as it would add maintenance overhead and risks of dependency relations bugs that would
be hard to catch.
Bonus question : why do we need libkompareinterface5 and libkompareinterface-dev in
the first place ?
Cannot we ship all the binaries in kpart5-kompare the same way konsole-kpart does and
skip shipping the headers entirely ?
I had a casual look at the code in both cases but couldn’t make enough sense as to why we
would need this difference.
I could find how yakuake uses konsole’s kpart just requesting the provided service by it’s
name, but there is no use of kpart5-kompare in the archive so I don’t know if it’s really
different, deeply broken or just a packaging artefact.
Happy hacking !
--
Aurélien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20200628/03107432/attachment-0001.html>
More information about the pkg-kde-talk
mailing list