Hello,

'Forewarned is fore-armed' as they say.

I noticed a few KDE/Plasma packages are are available to update to 5.23
in testing today. So far only three that I have installed, but the
number will obviously grow....

Taking note of the thread regarding updating to 5.23 in Sid, I'll be
holding off for a few days until migration to testing is complete.


--
Regards _
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
The public wants what the public gets
Going Underground - The Jam

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmwDAJZJEijHvlxs1Dz7gAfAqPiAFAmFsBfoACgkQDz7gAfAq PiAQ/wf+IuhdbWlJNNq1w0TVFR1r1uXUa6EhX37i9PuI+ezhEE4aBgtgFOvFeATe FPsziAQzwRkT1oh13JGV+r58GIOfGFvW2ujhpbQZhy+icl6qe8o36Lq7LHyLTS2p E3P+2Ac1T07q2RAu6scOGrivEK0aDNvMrjvltLfioFF1Rg6fJpY2yMIUSG9+uG4M V1xra1LZZC/wfWCMEpwR1RgKlibeFejj1K1xtGeEFFTzcxKkNomrp2mSrtE3dTZo +D358rA2QwDwFz2NWzBabxShTq2lZUHxFflkLoMwSUb5RlebN0phDJlAnLwSZccw 9dLYLBHR7e7o+7iZ0g/tapZPBQHySQ==
=rzCZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

17 Oct 2021, 07:16 by [email protected]:

Taking note of the thread regarding updating to 5.23 in Sid, I'll be
holding off for a few days until migration to testing is complete.

I'm sure this has been answered before, but this seems to be a perennial issue wherever there's a major upgrade. Since Testing is supposed to be free of known system-breaking errors, why can't the packages be held back until the it's all ready?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 19 Oct 2021 16:37:14 +0200 (CEST)
Borden <[email protected]> wrote:

17 Oct 2021, 07:16 by [email protected]:

Taking note of the thread regarding updating to 5.23 in Sid, I'll be holding off for a few days until migration to testing is complete.

I'm sure this has been answered before, but this seems to be a
perennial issue wherever there's a major upgrade. Since Testing is
supposed to be free of known system-breaking errors, why can't the
packages be held back until the it's all ready?

This not only has been answered before in general -- it has been
effectively discussed on this very list, only last week.

As a user, you can use "apt upgrade" or "aptitude safe-upgrade". With
either of these, you will not get half-system updates. If the whole
upgrade is ready, you'll get it; if it isn't, you will get suggestions
to either keep older versions of packages with updates, or drop the not-yet-updated packages. Then, you should choose what to do according
to your taste and the selection of not-yet-updated packages.

Asking for any non-stable flavor to act like stable is making the
packagers' work harder, and IMO as a grateful user who is not involved
in packaging, that is completely uncalled for.

Hope this helps,
Shai.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Erwan David ha scritto:

Le 19/10/2021 à 21:52, Shai Berger a écrit :

On Tue, 19 Oct 2021 16:37:14 +0200 (CEST)
Borden <[email protected]> wrote:

17 Oct 2021, 07:16 by [email protected]:

Taking note of the thread regarding updating to 5.23 in Sid, I'll be
holding off for a few days until migration to testing is complete.

I'm sure this has been answered before, but this seems to be a
perennial issue wherever there's a major upgrade. Since Testing is
supposed to be free of known system-breaking errors, why can't the
packages be held back until the it's all ready?

This not only has been answered before in general -- it has been
effectively discussed on this very list, only last week.

As a user, you can use "apt upgrade" or "aptitude safe-upgrade". With
either of these, you will not get half-system updates. If the whole
upgrade is ready, you'll get it; if it isn't, you will get suggestions
to either keep older versions of packages with updates, or drop the
not-yet-updated packages. Then, you should choose what to do according
to your taste and the selection of not-yet-updated packages.

Asking for any non-stable flavor to act like stable is making the
packagers' work harder, and IMO as a grateful user who is not involved
in packaging, that is completely uncalled for.

Hope this helps,
Shai.

With apt upgrade on testing, you often get partial non working upgrade.
I was recently told to "only do complete upgarde", but when I asked how
to know the upgrade is compelte, I got no answer.

Tonight apt list --upgradable lists me

Exactly: safe-upgrade is not safe when you need a bunch of packages to
migrated at the same time. You would get a mix which is going to be worse. In many cases the complete upgrade is better. This is about Shai's point.

That said, Erwin, I don't have an answer to your question. Probably stricter constraints in the packages may help, but not completely and it may be complicated to implement.

--
Luigi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

19 Oct 2021, 16:19 by [email protected]:

That said, Erwin, I don't have an answer to your question. Probably stricter constraints in the packages may help, but not completely and it may be complicated to implement.

Out of curiosity, how would the apt system have to change - strictly in theory - for something like this to be achieved?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 19/10/2021 à 21:52, Shai Berger a écrit :

On Tue, 19 Oct 2021 16:37:14 +0200 (CEST)
Borden <[email protected]> wrote:

17 Oct 2021, 07:16 by [email protected]:

Taking note of the thread regarding updating to 5.23 in Sid, I'll be
holding off for a few days until migration to testing is complete.

I'm sure this has been answered before, but this seems to be a
perennial issue wherever there's a major upgrade. Since Testing is
supposed to be free of known system-breaking errors, why can't the
packages be held back until the it's all ready?

This not only has been answered before in general -- it has been
effectively discussed on this very list, only last week.

As a user, you can use "apt upgrade" or "aptitude safe-upgrade". With
either of these, you will not get half-system updates. If the whole
upgrade is ready, you'll get it; if it isn't, you will get suggestions
to either keep older versions of packages with updates, or drop the not-yet-updated packages. Then, you should choose what to do according
to your taste and the selection of not-yet-updated packages.

Asking for any non-stable flavor to act like stable is making the
packagers' work harder, and IMO as a grateful user who is not involved
in packaging, that is completely uncalled for.

Hope this helps,
Shai.

With apt upgrade on testing, you often get partial non working upgrade.
I was recently told to "only do complete upgarde", but when I asked how
to know the upgrade is compelte, I got no answer.

Tonight apt list --upgradable lists me

bluedevil/testing,unstable 4:5.23.0-1 amd64 [upgradable from: 4:5.21.5-2] drkonqi/testing,unstable 5.23.0-1 amd64 [upgradable from: 5.21.5-2] kactivitymanagerd/testing,unstable 5.23.0-1 amd64 [upgradable from:
5.21.5-2]
kgamma5/testing,unstable 5.23.0-1 amd64 [upgradable from: 5.21.5-2] kinfocenter/testing,unstable 4:5.23.0-1 amd64 [upgradable from: 4:5.21.5-2] kmenuedit/testing,unstable 4:5.23.0-1 amd64 [upgradable from: 4:5.21.5-2] kscreen/testing,unstable 4:5.23.0-1 amd64 [upgradable from: 4:5.21.5-2] ksshaskpass/testing,unstable 4:5.23.0-1 amd64 [upgradable from: 4:5.21.5-2] kwayland-integration/testing,unstable 5.23.0-1 amd64 [upgradable from: 5.21.5-2]
libkdecorations2-5v5/testing 4:5.23.0-2 amd64 [upgradable from: 4:5.21.5-2] libkf5screen-bin/testing,unstable 4:5.23.0-1 amd64 [upgradable from: 4:5.21.5-2]
libkf5screen7/testing,unstable 4:5.23.0-1 amd64 [upgradable from:
4:5.21.5-2]
libpam-kwallet-common/testing,unstable 5.23.0-1 all [upgradable from:
5.21.5-2]
libpam-kwallet5/testing,unstable 5.23.0-1 amd64 [upgradable from: 5.21.5-2] plymouth-theme-breeze/testing,unstable 5.23.0-1 amd64 [upgradable from: 5.21.5-2]

and apt upgrade would upgrade them giving a mix of 5.21 and 5.23

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 19 Oct 2021, Borden wrote:

That said, Erwin, I don't have an answer to your question. Probably stricter
constraints in the packages may help, but not completely and it may be complicated to implement.

Out of curiosity, how would the apt system have to change - strictly in theory - for something like this to be achieved?

That is a question we are facing since long, and apt does not provide a solution. We want to force that updates can only be done in lockstep,
that is, packages cannot be updated to new major versions without
updating all.

But unfortunately, apt doesn't have an easy solution for that.
One idea was to make a virtual "abi package" (like we do for the PIM
packages) and inject dependencies so that each package depends on the
virtual abi package.
But this is also not very nice and easy a solution.

Best

Norbert

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 19 Oct 2021 16:37:14 +0200 (CEST)
Borden <[email protected]> wrote:

Hello Borden,

errors, why can't the packages be held back until the it's all ready?

Answered by others better ever than I could.

The action I take to avoid accidental upgrade is to pin anything
KDE/Plasma related involved in the upgrade until I'm (reasonably)
certain that everything has migrated. Obviously, reading this list
helps since people inform us of what's happening. Thank you to all that
do so.

Thanks also, of course, to the whole KDE team.

--
Regards _
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Tell the dinosaurs they just won't survive
The History Of The World (Part 1) - The Damned

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmwDAJZJEijHvlxs1Dz7gAfAqPiAFAmFv2hYACgkQDz7gAfAq PiCSnQf+Kmq6Hlek49XRLQ5Fh0kB2KNNh9QIj39VIRBY5u+D8eAFcjSPWkcrggwL nfnoCYIcYZQXGoNombOcnrk5McMoVPgnWyp58Cshgo+YC9/4+YTfdv8GEeW8eMSy D82AyXyorWpgbLrjHpUCkpVO0LDClpemDibRa9GrYyHs+FF7s6YdqdnaBUYdg/cr I9k/sgQwpXRnN6MrEkVjbks6E7jwp/qlQ2Ji98JWDibKW6+WfrG+VV1f5XzvLFoG KF6B6hsOUvBLBTrMsnk7pQpNSzDtxWpPPxA5OisuzdEe0+ZyV4GpyWPVLwN1rlaU BAgbu4Ms06YvpIe9OAjoD9SmuWLgnA==
=9xay
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.10.21 23:35, Norbert Preining wrote:

On Tue, 19 Oct 2021, Borden wrote:

That said, Erwin, I don't have an answer to your question. Probably stricter
constraints in the packages may help, but not completely and it may be
complicated to implement.

Out of curiosity, how would the apt system have to change - strictly in theory - for something like this to be achieved?

That is a question we are facing since long, and apt does not provide a solution. We want to force that updates can only be done in lockstep,
that is, packages cannot be updated to new major versions without
updating all.

But unfortunately, apt doesn't have an easy solution for that.
One idea was to make a virtual "abi package" (like we do for the PIM packages) and inject dependencies so that each package depends on the
virtual abi package.
But this is also not very nice and easy a solution.

Best

Norbert

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

Could it be an idea to let all KDE packages depend on the version of
something building part of the common core to all KDE apps, like "libkf5plasma5" (just an example, I am not sure if this specific package
would be the right candidate), and even if there is no change of code
for this package still increasing its (libkf5plasma5) version number as
needed for the desired apt result?

Thanks for KDE! Best wishes,
Marco.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oct. 19, 2021, 17:35 by [email protected]:

That is a question we are facing since long, and apt does not provide a solution. We want to force that updates can only be done in lockstep,
that is, packages cannot be updated to new major versions without
updating all.

But unfortunately, apt doesn't have an easy solution for that.
One idea was to make a virtual "abi package" (like we do for the PIM packages) and inject dependencies so that each package depends on the
virtual abi package.
But this is also not very nice and easy a solution.

Best

Norbert

Thank you, Norbert, for responding with helpful information. I appreciate your time.

If I understand you correctly, the design weakness is in the apt system itself and how it builds and navigates the dependency graph? Does the deb file standard provide the flexibility to provide this information, or would it have to be changed, too, in
an 'ideal system'?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)