I mean, if you’ve done something affecting upgrade paths - possible.
Also I broke a FreeBSD ufs partition once while upgrading OpenBSD. I thought I’m very smart having that added into disklabel, and it would successfully mount read-only. Well, there were some actions to upgrade OpenBSD’s own ufs partitions, so - I don’t really remember whether I could restore any data, TBF. I think I could still mount that read-only from OpenBSD, but not from FreeBSD.
I broke Arch when they switched to Systemd (the process that launches all other processes), and that’s because I was an idiot and partially applied the fixes without rebooting, so things got borked. I could’ve fixed it, but reinstalling was faster (like 30 min, and I kept my files; fixing could’ve taken a couple hours).
Other than that, I’ve had a couple drivers get misconfigured or something when upgrading Ubuntu or Fedora (I’ve had wifi and sound fixes not apply to an upgraded version), but I’ve never had an upgrade actually fail, and fixing it usually only took an hour or so to find someone online who has already provided the config options needed.
So yeah, I’ve had nothing like this on Linux in the 15 or so years I’ve used it, everything so far has been fixable with relatively minimal effort. Then again, I don’t use any fancy licensed software, so I haven’t needed to pull an old version of something along across multiple releases (almost got a Scrivener license, which no longer supports Linux).
But if those modifications were known to cause the system to brick after you update, wouldn’t it be really nice if it stopped you from doing it?
And not just “yeah we know having done x will cause a bootloop after update, if you don’t know to uninstall/fix it it first, too bad.”
Lets take VLC from this Windows example, the one that blocks windows updates is a really old version of it. If you have that, you need to either uninstall VLC or remove it to get Win 11 to update.
If there was a bug where having a really old version of VLC on your system would somehow break if you updated the kernel, would a complicated workaround patch be integrated into the kernel just in case for forever?
Or would the patch work exactly the same way as windows, where it would check for that version of VLC and tell you to remove or update it first?
I see you’re unaware of the number one rule of the Linux Kernel : DO NOT BREAK USER SPACE
The patch would be distributed the exact same way that we distribute every single other patch in Linux.
the exact same way that we distribute every single other patch in Linux.
Which is?
I see you’re unaware of the number one rule of the Linux Kernel : DO NOT BREAK USER SPACE
For sure, my linux experience is limited to playing around with raspis and the Steam Deck, and running apt-get update / upgrade and accepting everything at once. I haven’t actually even had a need to refuse updating something individually so I have no idea what the protocol is if I wouldn’t want to update some application.
What I do know is that basically every single linux application has dependencies and if you don’t install, update or remove exactly what that application demands you to do, most of them refuse to install or update themselves - blocking updating because you have or don’t have something else on your system seems to be basically the norm with Linux.
Directly patching the code, then letting the distros do their thing.
I have no idea what the protocol is if I wouldn’t want to update some application.
You’d just put it in an exclude list in your specific package managers config file for example. The depends are forward compatible and will just keep updating as normal. Very very rarely is there ever a case where forward compatibility is broken, and if it ever is the devs did so for a very thought out reason.
blocking updating because you have or don’t have something else on your system seems to be basically the norm with Linux.
It is yes. Because if you don’t have a library an application depends on then it just won’t run.
Except “have”, that’s not a real scenario; it’s always a matter of not having something; there’s packages that may conflict because they provide a different implementation of the same interface, but you’ll never be blocked by an application that depends on that interface.
The dependencies are defined by the distro maintainers when they packaged the software.
It ensures that package will function properly when installed.
If you really really want a really really old version of something that depends on deprecated dependencies/libs, there’s always portable and universal package solutions that include those specific deps with it instead of relying on system libs.
blocking updating because you have or don’t have something else on your system seems to be basically the norm with Linux.
i mean yeah, when it does happen that’s the correct failstate. The difference here is that it’s trivial to troubleshoot and maintain. The chance that this happens is very low, unless somebody is rearranging packages in your repo. In which case that’s an easy enough fix, and usually already scripted for. Something to do with AUR, which doesn’t touch pacman. Or some hilariously convoluted piece of software kerfuckery.
Usually it’ll be available as a flatpak or something, which is a special container that can have outdated dependencies and whatnot without impacting the rest of the system.
So if you really need some old version of VLC or something, just wrap it in a container and upgrade away! The upgrade would remove any incompatible apps (not containerized apps, just the system installed apps) and it would be on you to create or install that package if you haven’t already (almost everything old I’ve needed is already available).
So go ahead and use the VLC initial release from 2001 or whatever, you might need to do some archeology to get the right versions of dependencies though.
Imagine not being able to upgrade your Linux because you have modified YOUR system to suit YOUR needs. Fuck them…
I mean, if you’ve done something affecting upgrade paths - possible.
Also I broke a FreeBSD ufs partition once while upgrading OpenBSD. I thought I’m very smart having that added into disklabel, and it would successfully mount read-only. Well, there were some actions to upgrade OpenBSD’s own ufs partitions, so - I don’t really remember whether I could restore any data, TBF. I think I could still mount that read-only from OpenBSD, but not from FreeBSD.
But that’s about things being really broken.
I broke Arch when they switched to Systemd (the process that launches all other processes), and that’s because I was an idiot and partially applied the fixes without rebooting, so things got borked. I could’ve fixed it, but reinstalling was faster (like 30 min, and I kept my files; fixing could’ve taken a couple hours).
Other than that, I’ve had a couple drivers get misconfigured or something when upgrading Ubuntu or Fedora (I’ve had wifi and sound fixes not apply to an upgraded version), but I’ve never had an upgrade actually fail, and fixing it usually only took an hour or so to find someone online who has already provided the config options needed.
So yeah, I’ve had nothing like this on Linux in the 15 or so years I’ve used it, everything so far has been fixable with relatively minimal effort. Then again, I don’t use any fancy licensed software, so I haven’t needed to pull an old version of something along across multiple releases (almost got a Scrivener license, which no longer supports Linux).
But if those modifications were known to cause the system to brick after you update, wouldn’t it be really nice if it stopped you from doing it?
And not just “yeah we know having done x will cause a bootloop after update, if you don’t know to uninstall/fix it it first, too bad.”
Linux devs would just make a patch to work with that configuration as it’d be considered a bug.
How would that patch be distributed?
Lets take VLC from this Windows example, the one that blocks windows updates is a really old version of it. If you have that, you need to either uninstall VLC or remove it to get Win 11 to update.
If there was a bug where having a really old version of VLC on your system would somehow break if you updated the kernel, would a complicated workaround patch be integrated into the kernel just in case for forever?
Or would the patch work exactly the same way as windows, where it would check for that version of VLC and tell you to remove or update it first?
I see you’re unaware of the number one rule of the Linux Kernel : DO NOT BREAK USER SPACE
The patch would be distributed the exact same way that we distribute every single other patch in Linux.
Which is?
For sure, my linux experience is limited to playing around with raspis and the Steam Deck, and running apt-get update / upgrade and accepting everything at once. I haven’t actually even had a need to refuse updating something individually so I have no idea what the protocol is if I wouldn’t want to update some application. What I do know is that basically every single linux application has dependencies and if you don’t install, update or remove exactly what that application demands you to do, most of them refuse to install or update themselves - blocking updating because you have or don’t have something else on your system seems to be basically the norm with Linux.
Directly patching the code, then letting the distros do their thing.
You’d just put it in an exclude list in your specific package managers config file for example. The depends are forward compatible and will just keep updating as normal. Very very rarely is there ever a case where forward compatibility is broken, and if it ever is the devs did so for a very thought out reason.
It is yes. Because if you don’t have a library an application depends on then it just won’t run.
Except “have”, that’s not a real scenario; it’s always a matter of not having something; there’s packages that may conflict because they provide a different implementation of the same interface, but you’ll never be blocked by an application that depends on that interface.
The dependencies are defined by the distro maintainers when they packaged the software.
It ensures that package will function properly when installed.
If you really really want a really really old version of something that depends on deprecated dependencies/libs, there’s always portable and universal package solutions that include those specific deps with it instead of relying on system libs.
i mean yeah, when it does happen that’s the correct failstate. The difference here is that it’s trivial to troubleshoot and maintain. The chance that this happens is very low, unless somebody is rearranging packages in your repo. In which case that’s an easy enough fix, and usually already scripted for. Something to do with AUR, which doesn’t touch pacman. Or some hilariously convoluted piece of software kerfuckery.
Usually, it’s handled remarkably gracefully.
Usually it’ll be available as a flatpak or something, which is a special container that can have outdated dependencies and whatnot without impacting the rest of the system.
So if you really need some old version of VLC or something, just wrap it in a container and upgrade away! The upgrade would remove any incompatible apps (not containerized apps, just the system installed apps) and it would be on you to create or install that package if you haven’t already (almost everything old I’ve needed is already available).
So go ahead and use the VLC initial release from 2001 or whatever, you might need to do some archeology to get the right versions of dependencies though.
idk maybe if you can detec the specific issue, you should maybe like, tell the user.