Hi Aurélien, Aurélien COUDERC <li...@coucouf.fr> writes:
> Hi, > > Le vendredi 2 août 2024, 05:22:39 CEST Nicholas D Steeves a écrit : >> Shai Berger <s...@platonix.com> writes: >> >> > On Thu, 01 Aug 2024 17:17:17 +0200 >> > Aurélien COUDERC <li...@coucouf.fr> wrote: >> > >> >> Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann >> >> <alex-li...@wenlex.nl> a écrit : >> >> > >> >> >Yes, thanks. plasma5-integration was the missing bit. >> >> > >> >> >Maybe some packages need a depend/recommend on this package. As of >> >> >now, it stands completely on its own. >> >> > >> >> >$ apt-cache rdepends plasma5-integration >> >> >plasma5-integration >> >> >Reverse Depends: >> >> >> >> Yes, good idea, will do. >> >> >> > >> > FWIW, in testing there's "plasma-integration" and it has rdepends: >> > >> > $ aptitude why plasma-integration >> > i task-kde-desktop Depends kde-standard >> > i A kde-standard Depends kde-plasma-desktop (>= 5:148) >> > i A kde-plasma-desktop Depends plasma-desktop (>= 4:5.27.11) >> > i A plasma-desktop Depends plasma-integration (>= 5.27.11~) >> >> Package: plasma-desktop >> Version: 4:6.1.3-1 [experimental] >> [snip] >> Depends: [snip] plasma-integration (>= 6.1.0~) > > … which is fine, this package is the integration for Qt6 apps. > plasma5-integration is required for Qt5 apps in addition. Aha! >> The other end up transitively depending on it because of this. I'm >> guessing that the nature of this issue is that one should never >> 'dist-upgrade'/'full-upgrade' when mixing experimental; however, in this >> case I'm guessing that this was needed in order to install a new >> package. >> >> Aurélien, do you think upgrades could be smoother for users if >> plasma-integration (and/or any other packages) had stronger breaks & >> replaces, or will everything 'just work'? > > I don’t get what you mean by that. Yes, we must have a working upgrade path > and we make what we can to make it happen. > When someone finds an issue like here with missing plasma5-integration or > previously with qml6-qtmql-workerscript we fix it. What I understood was that whoever updated the source package believed that our new bin:plasma-integration logically provided plasma5-integration (whether or not it had formal Provides). I found this reasonable and didn't question it. Otherwise I expect to see a bin:"plasma6-integration" package. In other words, it looks like a transition from versioned (ie plasma5-integration) to unversioned (ie plasma-integration) binary packages. Usually such transitions must include versioned breaks and replaces. In this case it would be wrong to have versioned provides. > We generally install all packages from the stack when packaging to ensure > that nothing breaks when upgrading. So we don’t catch the missing package > issues immediately. Of course :) So in this case I wonder if it would save time to somehow search for all versioned-2-unversioned bin:packages, and then add Recommends for the old Qt5/KF5/Plasma5 variant, run autopkgtests and piuparts, and make a list of failures. These failures indicate where the 5-variant package no longer exists, and these are the cases that require actual investigation. The success list can probably just be skimmed by someone who would recognise if it's a likely case where the old 5-variant is still required for compatibility. Regards, Nicholas
signature.asc
Description: PGP signature
