[RFC] pkg-kde-tools: auto-injections of dependencies

Norbert Preining norbert at preining.info
Sat Nov 28 10:54:39 GMT 2020


Hi all

I am planning to merge this MR and release a new version, unless
people speak up against the approach here.

Agreement statements are also welcome ;-)

Best

Norbert

On Wed, 25 Nov 2020, Norbert Preining wrote:
> Hi all
> 
> I would like to ask your comments concerning the following MR:
> https://salsa.debian.org/qt-kde-team/pkg-kde-tools/-/merge_requests/5
> 
> Next is the text of the MR, and below it some technical explanation and
> usage for locked upgrade of Plasma.
> 
> ***** Text of the MR starts here *****************
> Aim of this MR is to allow for auto-injection of plasma-base dependencies
> (as discussed on IRC and mailing list) by doing the following:
> 
> - add a new script `dh_injectdependencies` which can add arbitrary
>   dependencies like 
>     `dh_injectdependencies breaks: "plasma-base (>= 5.22)" depends: "plasma-base (>= 5.21)"`
> - add a DebHelper sequence `injectdependencies` so that one can use it with `--with`
> - add a `plasma.mk` makefile snippet that auto-computes the correct versions and inject them.
> 
> As an example, I changed one Plasma package `debian/rules` file to:
> - add
> 	include /usr/share/pkg-kde-tools/qt-kde-team/1/plasma.mk
> - add `Breaks: ${misc:Breaks}` to each binary package stanza
> - add `injectdependencies` to the `--with` list
> 
> In total it starts as:
> ```
> include /usr/share/pkg-kde-tools/qt-kde-team/1/plasma.mk
> 
> %:
>         dh $@ --with kf5,pkgkde_symbolshelper,injectdependencies --buildsystem kf5 --without build_stamp
> ```
> 
> 
> With that, each binary package gets (for version 5.20.3) additional
> ```
> Depends: plasma-base (>= 5.20)
> Breaks: plasma-base (>= 5.21)
> ```
> 
> The above changes have to be done only once, and new versions will
> automatically pick up the correct major.minor dep/break.
> 
> 
> Questions
> ==========
> 
> I had contemplated putting the code of the injectsequences into the
> kf5 sequence (Debhelper), it only adds a call to dh_injectsequences
> before `dh_gencontrol`, and without an override it does nothing.
> By that, no addition to the `--with` code is necessary. What do other
> think about this approach?
> 
> Another thing to ponder is renaming the script to `dh_injectrels` or
> `dh_injectrelations`.
> **** End of MR text *********************
> 
> Concerning implementations:
> 
> - few stuff for building the package
> 
> - dh_injectdependencies is rather simple, it loops over all binary
>   packages and adds the given packages to the respective variables.
>   We use ${misc:Depends} (which is commonly used), but add in the
>   same way ${misc:Relation} for each relation between packages
>   (${misc:Breaks} etc ...)
> 
> - the Debhelper sequence injectdependencies simply adds a call to
>   dh_injectdependencies *before* dh_gencontrol
> 	insert_before("dh_gencontrol", "dh_injectdependencies");
>   Without and explicit override, this is a noop.
> 
> - finally the plasma auto detection magic in qt-kde-team/1/plasma.mk
>   This uses /usr/share/dpkg/pkg-info.mk for getting DEB_VERSION_UPSTREAM
>   and compute the Major and Minor and Patchlevel version from it.
>   As a special case, if the patchlevel >= 70 (eg 5.20.70) we use
>   the next minor version (-> 5.21).
>   Then it adds a override_dh_injectdependencies with breaks on
>   the next version of plasma-base, and depends on the current version
>   of plasma-base
> 
> The NEW package plasma-base
> (https://salsa.debian.org/qt-kde-team/kde/plasma-base)
> currently breaks against all plasma packages << 5.20 to ensure that
> all Plasma packages are updated together to new releases.
> 
> The idea is that we can keep plasma-base at the previous version, and
> thus ensure that the new packages cannot be partially installed, and
> only bump plasma-base when all packages are ready. This way a concerted
> update will be done.
> 
> All plasma packages have in their git repo now a branch "dh-plasma" that
> adds the necessary ${misc:Breaks} and debian/rules adaptions to build
> with these new dependencies.
> 
> I have tested all binary packages one by one so that 
> - install version from unstable
> - update only the one binary package to 5.20.3
>   this will make apt update several other packages, too
> - check that no package remains at 5.19 level
> 
> 
> Please let me know what you think about this approach.
> 
> Thanks
> 
> Norbert
> 
> --
> PREINING Norbert                              https://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
> 
> -- 
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-kde-talk

--
PREINING Norbert                              https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



More information about the pkg-kde-talk mailing list