On Sun, 9 Nov 2025 at 11:22, Aurélien COUDERC <[email protected]> wrote:
> Hi, > > Le 9 novembre 2025 09:59:16 GMT+01:00, Sami Erjomaa < > [email protected]> a écrit : > >On Sun, 9 Nov 2025 at 10:21, Aurélien COUDERC <[email protected]> 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 -- Sami Erjomaa
