Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Posted May 22, 2024 16:57 UTC (Wed) by NYKevin (subscriber, #129325)In reply to: Versioning packages for breaking upgrades by epa
Parent article: The KeePassXC kerfuffle
Posted May 22, 2024 17:21 UTC (Wed)
by jzb (editor, #7867)
[Link]
"If the user has to parse semantic version information at all, you have already failed." I'd add that users rarely engage with version numbers of packages anyway. When I do an update I'm not examining each package version number - the only times that I would are when I'm specifically interested in a security update or a version update to get a new feature, etc.
Posted May 23, 2024 5:27 UTC (Thu)
by epa (subscriber, #39769)
[Link] (20 responses)
Posted May 23, 2024 6:24 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (18 responses)
We're talking users here, not sysadmins. An admin can be expected to read the update notes and, say, replace exim4-core with exim4-heavy when they need an uncommon feature that's been chopped off the standard package.
However, this case is different. There's nothing uncommon in KeepassXC's browser integration. I'd use some other password manager if that didn't exist. Again: we're talking "normal" users here. Somebody who is security-hyper-conscious can be expected to manually replace keepassxc with keepassxc-minimal, along with all the other stuff that needs replacing or restricting for these use cases.
Posted May 30, 2024 13:05 UTC (Thu)
by mrugiero (guest, #153040)
[Link] (12 responses)
I get your point, but we're not talking about normal users here. We're talking users who are in the tiny subset that opted for the rolling release version of Debian (which means breakage is not just possible, it's what you should expect) and then the tinier subset that chooses an old school local password store over a service.
Posted May 30, 2024 14:28 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (11 responses)
If I want to upload something to Debian with a breaking change that I'm going to rework before unleashing it to the masses, I should upload to Experimental instead. Alternately I can add an RC bug (Release Critical) which would prevent the package to get get promoted to Testing, but that's sort of frowned upon because one can block transitions that way.
To be sure, Upstream isn't entirely blameless either. I don't know what the correct way to disable optional features people depend on might be in this context – but silently hiding them appears not to be The Way.
Posted May 30, 2024 14:59 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
No, today's users of Testing are tomorrow's users of Testing -- Once you explcitly opt in to using it, you remain on it. When a new stable release is cut, users of Testing don't automatically get switched over to it. [1]
As for assumptions, let me quote the Debian wiki ( https://wiki.debian.org/DebianTesting )
> How Debian Testing Works
Note the word "automatically". In other words, "Debian unstable as of about a week ago minus anything with release critical bugs" -- and in order for there to not be any "release critical bugs" someone has to first *report* said bug against the package while it's still in the Unstable repository.
Once again, this kerfuffle stems from users expecting something "stable" while explicitly opting in to something that, by its very definition (and name!), is not.
[1] Strictly speaking it depends on how they've opted into testing -- if they use the "next stable" name (eg "trixie") instead of "testing", they'll eventually land and stay on that stable release indefinitely, but if they opt into "testing" they will stay on testing. This is also documented on the wiki page mentioned above.
Posted May 30, 2024 15:22 UTC (Thu)
by rschroev (subscriber, #4164)
[Link] (1 responses)
> No, today's users of Testing are tomorrow's users of Testing
But todays packages in testing are tomorrow's packages in stable. That's the important thing here. Were it not for the users of testing raising the alarm today, the removal of functionality would have gone in tomorrow's stable. The problem here is not so much that users of testing were impacted, but mainly that all users would be impacted sooner or later if things would have gone the way the maintainer intended.
> Once you explcitly opt in to using it, you remain on it. When a new stable release is cut, users of Testing don't automatically get switched over to it.
It depends: if you select 'testing' in your sources list, than you will indeed stay on testing. But if you select 'trixie' (which is at the moment the same as 'testing'), you will be on stable when trixie becomes stable.
Posted May 30, 2024 15:38 UTC (Thu)
by pizza (subscriber, #46)
[Link]
No, they are tomorrow's packages in *stable+1*. Nothing ever flows from testing into stable (or oldstable).
(And to use your analogy, today's packages in unstable are the day after tomorrow's packages in stable+1 too..)
> That's the important thing here. Were it not for the users of testing raising the alarm today, the removal of functionality would have gone in tomorrow's stable. The problem here is not so much that users of testing were impacted, but mainly that all users would be impacted sooner or later if things would have gone the way the maintainer intended.
Well, yes -- but you're just restating how Debian's staged development process is intended to work, including the user feedback loop.
Again, this sort of situation is the *entire point* of debian-testing.
Posted May 31, 2024 3:31 UTC (Fri)
by mrugiero (guest, #153040)
[Link] (7 responses)
https://wiki.debian.org/DebianUnstable
This happened in unstable, didn't it? It is a rolling release where breakage is expected and packages from unstable DO NOT flow into (current) stable under any conditions. These changes only make it to the NEXT stable release, which you do a manual, major, opt-in upgrade, only if you wish to. If you are NOW on unstable, you expect breakage, end of story.
Also, my comment was not so much about the size of the group, but about the demographics. The people affected made two choices that made them very much not normal users. It's not your tech oblivious auntie that is using keepassxc on unstable. You didn't mistakenly bought a laptop with Debian unstable preinstalled and didn't know any better. You chose it. The one with the big "unstable" label in the name. You can't expect the stability guarantees the name itself says it won't deliver on and then complain because it didn't, that's unreasonable.
Re: users reporting to upstream: same misfeature. You use a distro, you should check what your distro did first. Specially if you go ahead and use unstable. The maintainers have a right to be annoyed. I sympathize specially with their work being called "crap" by the packager. But really, the ones that are in the wrong are mostly the users IMO, sans unhealthy communication styles. They complain to the wrong people about broken promises that nobody made, all while having the solution to their issues in the NEWS file they didn't read.
Posted May 31, 2024 11:34 UTC (Fri)
by rschroev (subscriber, #4164)
[Link] (6 responses)
I don't see how it happening in unstable is an excuse. Of course it happens in unstable, that's where Debian development is done. Are users only allowed to file reports when an issue is noticed in stable? That makes no sense at all. Unstable and testing exist precisely to fix issues before shipping the next stable. We should praise people for reporting issues, not blame them because 'they should expect breakage'.
And of course this new keepassxc would not have gone in the current stable, but in the next one. That doesn't make it any better. People rightly expect upgrades from one stable to the next not to break things unless there's a good reason for it, and I agree with people who say that this loss of functionality does not have good reason.
Posted May 31, 2024 11:45 UTC (Fri)
by mb (subscriber, #50428)
[Link] (4 responses)
Sorry, but that expectation is completely wrong.
>unless there's a good reason for it, and I agree with people who say that this loss of functionality does not have good reason.
Ok. But other people think that a decrease in attack surface is a good reason.
Keep in mind that this is not just any random packet. It literally is the key to everything.
You can still install the full package. I really don't see what's so special here. Stuff like this happens all the time when upgrading the system. That's why people should read the upgrade news.
Posted May 31, 2024 14:44 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
Yeah. In between. As in, things might be somewhat broken while you're developing the Next Great Release, but when you're ready to burn another Stable (which in Debian is supposed to mean "when they migrate to Testing" but obviously doesn't always) they're back to being unbroken.
This stuff needs to be discoverable. Either you get a "do you want/need the full version" prompt on upgrade (which is what the maintainer seems to be planning), or a "hey you'll need the bells-and-whistles version for this" message when you try using a feature that's now only in -full (which requires support from upstream).
"Read the NEWS files" isn't that helpful when a distribution has a heap of packages with more-or-less-breaking changes, 90% of which don't apply to me and/or I could care less about. Keep in mind that the NEWS's audience is developers and sysadmins as well as "users" (who when they don't admin their own computers don't even get to read the NEWS files, and if they do the info/chaff ratio is even worse).
Posted May 31, 2024 14:50 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Sorry, no. Again, let me quote the Debian wiki ( https://wiki.debian.org/DebianTesting )
> How Debian Testing Works
Again. *TESTING IS NOT STABLE* And that is the entire point of having it. To find issues *before* a new stable release is cut.
Posted May 31, 2024 14:53 UTC (Fri)
by rschroev (subscriber, #4164)
[Link] (1 responses)
The reason for stable releases is that they are stable, and that does indeed imply that there's a lot less stability from one stable release to the next. Breaking changes are sometimes unavoidable, and by having stable releases those breaking changes happen between stable releases. That doesn't mean we have to have breaking changes; I'll argue we should strive to keep that to the absolute minimum possible.
> Ok. But other people think that a decrease in attack surface is a good reason.
I have to admit, I do see a point there: in the scenario where keepassxc keeps it full functionality and a new package keepassxc-min is created, people who don't read the detailed release notes (i.e. when it comes to desktops most people, I assume) would never know about keepassxc-min. Whereas in the scenario where keepassxc loses its functionality and a new package keepassxc-full is created, people would quickly find out that their use case is not supported anymore, and will hopefully quickly find out that they can transition to keepassxc-full.
Posted May 31, 2024 20:25 UTC (Fri)
by mrugiero (guest, #153040)
[Link]
Breaking changes for the sake of it, right, undesirable. But they do happen and they are expected between stable releases, and they are expected in unstable. The whole point is that you have stability as long as you don't migrate to next stable, not that the whole distro is forever stagnant.
> I have to admit, I do see a point there: in the scenario where keepassxc keeps it full functionality and a new package keepassxc-min is created, people who don't read the detailed release notes (i.e. when it comes to desktops most people, I assume) would never know about keepassxc-min. Whereas in the scenario where keepassxc loses its functionality and a new package keepassxc-full is created, people would quickly find out that their use case is not supported anymore, and will hopefully quickly find out that they can transition to keepassxc-full.
And that's precisely the point. The package manager was designed precisely to allow this. You have transitional packages to force choices, software that informs you of manual intervention you may require, and a release model that doesn't push such changes to a given stable release. But at the moment you opt-in to upgrade, you are expected to give care to such possible breaking changes.
Posted May 31, 2024 20:25 UTC (Fri)
by mrugiero (guest, #153040)
[Link]
It's not just mistakes and incompatibilities. As you said, that's where development happen. That's where you have the chance to make breaking changes if you judge they are needed. The packager judged them needed and so he introduced them.
> Deliberately removing functionality without a very good reason, I'm not so sure that is what someone should expect. But OK, it can happen.
Your very good reasons may be my irrelevant excuses. The packager gave his reasons and it does sound like the original package had more things than Debian packages tend to bring by default. Most other packages have plenty of optional dependencies and what not.
> But when people report that e.g. they can't open their password database anymore because their is no support for hardware keys anymore and they're not taken seriously, that is not to be expected.
That may have been wrong, yeah.
> When people ask to "Put the base package back where it was and create a keepassxc-minimal" and get "that's not going to happen" as an answer, that's not to be expected. That's going to upset people.
Demands and asks are two different things. The packager offered a solution, which was a keepassxc-full. The users decided pointing to the other package was too much work, apparently.
> I don't see how it happening in unstable is an excuse. Of course it happens in unstable, that's where Debian development is done. Are users only allowed to file reports when an issue is noticed in stable?
Certainly not. You can and should file issues against unstable. But that's moving the goal post, we were arguing whether you should expect a flawless break-free experience on unstable and whether that's a fair expectation. Demanding the solution to be "keep my setup as it is" when running on unstable is what's out of place. It's the place where breakage is allowed and you opted in, you deal with some changes that require manual intervention, such as moving to keepassxc-full. If it still breaks because of bad packaging, then it's a different story.
> That makes no sense at all. Unstable and testing exist precisely to fix issues before shipping the next stable. We should praise people for reporting issues, not blame them because 'they should expect breakage'.
We should praise them for testing, reporting, etc. Not for demanding a change be reverted just because it breaks a stability promise that nobody made. Certainly not for bothering the wrong person.
Posted May 31, 2024 9:31 UTC (Fri)
by Duncan (guest, #6647)
[Link] (4 responses)
I beg to differ.
A user that does system package upgrades is by definition administrating the system when they do so, which by definition makes them a system administrator, if only of their own personal system(s), and users with the privileges to do system administration should absolutely take that role as seriously as the title suggests, thereby minimizing issues such as this as they /will/ have read those news items, /especially/ if in their system administrative role they've made the choice to run unstable/testing as opposed to stale^H^Hble.
> An admin can be expected to read the update notes and, say, replace exim4-core with exim4-heavy when they need an uncommon feature that's been chopped off the standard package.
There we agree! =:^)
> Again: we're talking "normal" users here.
There we disagree. It's in the basic definition of "user" vs. "system admin". Facts are facts, if you're installing system software, you're a sysadmin, and if you fail to take that responsibility seriously you're doing so at both your own peril and the community peril of potentially spreading any malware you may activate as a result of that failure.
> Somebody who is security-hyper-conscious can be expected to manually replace keepassxc with keepassxc-minimal, along with all the other stuff that needs replacing or restricting for these use cases.
Regardless of whether one thinks the default should be the full or the secure package, that said default was changed without the customary transitional package, etc, is "unfortunate", but that's exactly the sort of to-be-found/reported/fixed bugs that unstable/testing sysadmins have (in that role) opted into by choosing to be the guinea pigs that do just that so it can be fixed before it reaches stable. As such, it isn't, or at least shouldn't be, a major problem at all.
Posted May 31, 2024 11:18 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
And there you are living in a perfect world where everything is neatly laid out as it should be.
I live in the real world, where I am a *gentoo* *user*. Read into that what you will ...
Cheers,
Posted May 31, 2024 12:21 UTC (Fri)
by jem (subscriber, #24231)
[Link] (1 responses)
I once maintained Gentoo on my own computers, but switched to Arch Linux, not least because I realized Gentoo is not very ecological. Ok, maybe that doesn't matter so much with a market share of 0.08%, but "Gentoo World Domination" would be a disaster with everybody compiling the world once a day.
Posted May 31, 2024 15:56 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Because it helps me learn a little bit more about modern Linux. I date from the days before Windows - when there was a lot more to home computers than DOS - and it was possible to (at least superficially) understand everything there was to understand. The first computer I really worked with ran 20 users off 256KB of ram ... my next employer bought one of the very first HP LaserJets in the UK, and things are just getting toooo complex to understand. Gentoo, where I at least have *some* control of what's going on, gives me a deeper understanding. I like to know the detail, but my strength always lies in having an overview at a deeper depth than anyone else around me ... :-)
> not least because I realized Gentoo is not very ecological. Ok, maybe that doesn't matter so much with a market share of 0.08%, but "Gentoo World Domination" would be a disaster with everybody compiling the world once a day.
Given the obsession of humanity to have an "always on" archive of everything we've ever know (YouTube, the Wayback machine, BigQuery, Facebook, etc) and our habit of "let the computer do it rather than use our brains" - you know, AI, SQL databases, monte carlo predictions, I think a successful Gentoo World Domination would be but a drop in the ocean.
Oh - and did you know Gentoo (can be) a binary distribution now? Okay, when I had a farm of machines, I would upgrade them at random but they were configured to share the same download archive, and create and store binary packages to save compilation, but now the mirrors themselves carry binary packages for most common USE flag sets.
They've carried binaries for the hogs - Chrome, Firefox, LibreOffice, Rust, gcc et al - for ages, but now they carry binaries for most things.
Cheers,
Posted Jun 8, 2024 4:56 UTC (Sat)
by fest3er (guest, #60379)
[Link]
Posted May 23, 2024 8:49 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
However, the version number is not used for this purpose. Instead, you have to go the virtual package route. Unfortunately, because it requires manual intervention, it will cause anything running unattended-upgrades to silently* fail to upgrade, and just sit on the old version forever. It's acceptable in this case for two reasons:
1. They are delaying it until the next stable release, which means the current stable won't be broken. Nobody expects unattended-upgrades to successfully apply a full distro upgrade.
* Yes, you can set up various kinds of remote monitoring such as apt-listchanges. But by the time you go to the trouble of doing that, and configure an MTA, and get all of the DKIM/SPF/etc. nonsense to a place where random people are not putting your IP address on the naughty list, and so on, you're in full-blown cattle-not-pets territory, and unattended-upgrades is probably the wrong abstraction for that purpose anyway.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
I get that it's normal to expect browser integration, but you already left "normal" users out from preconditions. And yeah, your distro says in big letters "unstable", if you don't expect changes it's a layer 8 bug. If you want big warnings when things change, or not change at all, stable is there for you.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
>
>Packages from Debian Unstable enter the next-stable testing distribution automatically, when a list of requirements is fulfilled:
>
> The package has been in "unstable" at least for 2-10 days (depending on the urgency of the upload).
> The package has been built for all the architectures which the present version in testing was built for.
> Installing the package into testing will not make the distribution more uninstallable.
> The package does not introduce new release critical bugs.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
>
> As with all Debian release names, Sid takes its name from a ToyStory character. In the movie, Sid is the kid next door who breaks his toys and makes nasty creatures of them.
>
> While other release code names progress in time from being "testing" to being "stable", Sid is forever doomed to being unstable. Sid will always be the unstable branch. When the current "testing" repository becomes mature and is released, "testing" becomes the latest "stable" release. From there, a new "testing" repository will be created with the next planned code name, and packages will continue to trickle down from Sid into "testing" just as before.
>
> Sid is where packages go after they've been uploaded by their maintainer, and cleared for release by the FTP master. When packages have met certain criteria, they are automatically moved from Sid to the current "testing" repository. The "Unstable" repository is updated every 6 hours.
I don't think experimental is about breaking changes but rather potentially harmful software, due to an unfinished nature. This isn't the case from my POV, but rather a mere change on packaging. Does it need testing? Yeah. Does it break the existing workflow of some users? Yes, too. But is the software itself broken or dangerous to use? No. Then, unstable. It is the right repo.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
The only reason for having stable releases is to have breaking changes in between.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
>
>Packages from Debian Unstable enter the next-stable testing distribution automatically, when a list of requirements is fulfilled:
>
> The package has been in "unstable" at least for 2-10 days (depending on the urgency of the upload).
> The package has been built for all the architectures which the present version in testing was built for.
> Installing the package into testing will not make the distribution more uninstallable.
> The package does not introduce new release critical bugs.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Essentially, the difference is in the definition of bug for each case. For stable, if your current config no longer works, it is a bug. For unstable, that is simply a change that requires manual intervention, and only proper software flaws are bugs.
But in any case, when you use a distro package you check their issue tracker first, before bothering upstream. It's common sense, upstream doesn't have the same version.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Wol
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Wol
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
2.keypassxc is an interactive app, so breaking unattended-upgrades is less of a catastrophe (the user is more likely to notice that an upgrade is pending but failing to apply).