3 ms·

If you replace the version of python that the upgrade process expects, then yeah, you'll probably run into problems. The upgrade process can't possibly support

by md8z 5y ago

If you replace the version of python that the upgrade process expects, then yeah, you'll probably run into problems. The upgrade process can't possibly support every single version of any given package, that would defeat the entire purpose of having a stable release cycle. If it's a core package like python which sits really close to the top of the dependency tree then the effects of swapping that out will cascade downward and that's why everything breaks so badly. In my experience, this is the only safe way to have third party apt repositories: - Don't install any third party packages which have reverse dependencies. This means no libraries, only applications. If you need newer libraries as a dependency then you have to statically compile the application. - Don't install any third party packages which have the same name as an upstream package. If you want to install a newer third party version of an upstream package then you need to change the name of it and have it install all of its files in different locations. A prefix change is enough here, /opt is a popular choice. - Delete all third party packages before doing an upgrade, in case a new upstream package happens to have the same name, or needs to put files in the same locations. Do anything outside of that and you will risk getting your install into a broken state. Because even though you might think you are just installing some applications, what you are really doing is bolting things on to the upgrade process for the entire core system. Using nvm is perfectly safe though because that just installs the different versions to your home directory, it doesn't touch apt.

josephg 5y ago
That makes sense; though to be clear, you're essentially saying that apt isn't appropriate for 3rd party packages. And that: - The question of which files go in which directories in the system is a question for canonical (or whoever) to decide. Not end users or 3rd party developers - The namespace of apt package names is special, and 3rd party / external dpkgs shouldn't add anything into it I think this stance is entirely reasonable. Its essentially what windows and macos both do (and to increasing degrees with each version). But its a pity its taken the current apt packaging disaster to realise it. Its really convenient for users to have a package manager, and for 3rd party developers be able to write software for it. And these problems seem solvable: - Namespace all 3rd party packages. Eg, @apple/foundationdb-server (as distinct from @canonical/git) - Use overlayfs or something to essentially make /usr, /usr/bin, etc read only by normal processes. If these paths were only writable by system packages, the whole system would be much more predictable (and verifyable) - since that filesystem would only - could only contain a subset of the files in apt. I get that flatpak and snap are both attempts to replace apt. But its a pity they're needed. I'm enjoying mint, but if I ever rebuild this machine I'm going to give nix a try.
- md8z 5y ago
  Yes to all of the above. Although namespacing is not enough, the packages need to be built in a specific way so that they don't put files in any system locations. This isn't anything specific to Ubuntu, this is just how Debian works. If you want to do things "the right way" you're supposed to submit your packages upstream and be patient. This is not exactly a new problem, it's why Docker is popular, it's why Fedora Silverblue and NixOS exist. It's just not done on the OS level in Debian because in some ways it doesn't really need to be.

by md8z 5y ago

josephg 5y ago

That makes sense; though to be clear, you're essentially saying that apt isn't appropriate for 3rd party packages. And that: - The question of which files go in which directories in the system is a question for canonical (or whoever) to decide. Not end users or 3rd party developers - The namespace of apt package names is special, and 3rd party / external dpkgs shouldn't add anything into it I think this stance is entirely reasonable. Its essentially what windows and macos both do (and to increasing degrees with each version). But its a pity its taken the current apt packaging disaster to realise it. Its really convenient for users to have a package manager, and for 3rd party developers be able to write software for it. And these problems seem solvable: - Namespace all 3rd party packages. Eg, @apple/foundationdb-server (as distinct from @canonical/git) - Use overlayfs or something to essentially make /usr, /usr/bin, etc read only by normal processes. If these paths were only writable by system packages, the whole system would be much more predictable (and verifyable) - since that filesystem would only - could only contain a subset of the files in apt. I get that flatpak and snap are both attempts to replace apt. But its a pity they're needed. I'm enjoying mint, but if I ever rebuild this machine I'm going to give nix a try.

md8z 5y ago
Yes to all of the above. Although namespacing is not enough, the packages need to be built in a specific way so that they don't put files in any system locations. This isn't anything specific to Ubuntu, this is just how Debian works. If you want to do things "the right way" you're supposed to submit your packages upstream and be patient. This is not exactly a new problem, it's why Docker is popular, it's why Fedora Silverblue and NixOS exist. It's just not done on the OS level in Debian because in some ways it doesn't really need to be.