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