Hi,
Le 9 novembre 2025 09:59:16 GMT+01:00, Sami Erjomaa <sami.erjomaa@gmail.com> a écrit :
>On Sun, 9 Nov 2025 at 10:21, Aurélien COUDERC <libre@coucouf.fr> wrote:
>Hi,
>
>Wouldn't this force a rebuild of all the packages that depend on the
>plasma-version-base-${plasma-version:major}.${plasma-version:minor} every
>time when the version changes?
And how would would you expect packages not to be rebuilt when there's a new upstream version ?
I've understood that not all packages get a new upstream version on each release. So there could be a case where some packages remain in for example version 6.5 when 6.6 is released.
>Could this same or at least similar result be reached with stricter
>dependencies in the packages?
>Example: currently plasma-workspace has dependency kwin-wayland (>=
>4:6.2.90~). What if this and all the similar dependencies are updated to
>something like kwin-wayland (>=
>4:${plasma-version:major}.${plasma-version:minor}~). Wouldn't that prevent
>installing plasma-workspace in testing before kwin-wayland has also
>migrated?
Yes it would.
But I'm not willing neither to identify these relationship manually that are already not explicit in the upstream build system, and even less to manage their maintenancd for every new release.
I wouldn't do that manually either. I thought that the same script could be used to automate the dependencies.
My proposal is a one-time addition of dh-sequence-plasma to the build deps and then we're back to the current process when a new release comes with no additional steps for the 60+ plasma packages. Just one upload of plasma-version.
Happy hacking,
--
Aurélien