[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