The majority of Linux distributions out there seem to be over-engineering their method of distribution. They are not giving us a new distribution of Linux. They are giving us an existing distribution of Linux, but with a different distribution of non-system software (like a different desktop environment or configuration of it)
In many cases, turning an installation of the base distribution used to the one they’re shipping is a matter of installing certain packages and setting some configurations. Why should the user be required to reinstall their whole OS for this?
It would be way more practical if those distributions are available as packages, preferably managed by the package manager itself. This is much easier for both the user and the developer.
Some developers may find it less satisfying to do this, and I don’t mean to force my opinion on anyone, but only suggesting that there’s an easier way to do this. Distributions should be changing things that aren’t easily doable without a system reinstall.
Suppose kubuntu, ubuntu, lubuntu, xubuntu were packages to be installed on top of debian.
How would you do that? Debian would not create and maintain a “core debian” variant just to be installed then receive the extra packages. Would the *ubuntu packages replace, instead of add on top of default debian packages?
Then where would the updates come from? Both debian and *ubuntu repositories?
What about dependencies? Would debian have to coordinate with all *ubuntu maintainers (and they too, between them) for compatibility tests every time debian needed to update one of its packages? Or they’d just update and *ubuntu would have to scramble to release fixes for what had been broken?
Not to mention convenience; would you have to download debian, download *ubuntu, install debian, then your *ubuntu?
Why not then package the “core debian”, with the tested component versions that work with the *ubuntu packages you’re downloading? Hey, and what about script the installation to install both “core debian” parts and then *ubuntu automatically? That’s an innovative idea indeed. No, wait, isn’t it sort of what they already do today?
It’s not like there’s a Linux headquarters with a centralized organization that releases all multiple distros just to feed the hobby of distro hoppers. Distros are maintained and packaged by different people, and it’s already a lot of trouble to keep each part in sync.
Debian server minimal, is kind of a “core Debian”. There are netinst versions that can be even smaller. The Debian base image for Docker is even smaller than all that.
There is also an Ubuntu minimal install that you could call “core Ubuntu”.
But more importantly, and I can’t stress this enough: YOU CAN SWITCH DISTROS WITHOUT REINSTALLING. Might need to do some cleanup afterwards, but it’s perfectly doable, more so between Debian based ones.
Uninstalling the entire kubuntu package, while reverting to “core Debian” and then installing the Ubuntu package would be more complicated and time-consuming than installing a new OS.
Just partition off your /home and a reinstall won’t be that big a deal.
I want kubuntu?
Step 1: install Ubuntu (the farthest ancestor of kubuntu that does more than change non system packages) Step 2: install kubuntu package: sudo apt install kubuntu
Oh well, I decided I want lubuntu instead
Step 1: uninstall kubuntu: sudo apt remove kubuntu Step 2: install lububtu: sudo apt install lubuntu
That is my proposal. It is WAY simpler than reinstalling.
A minimal install like debian base already has a things that may differ from distro to distro. Or are you equating “distro” with window manager and GUI customizations? Even the kernel binaries may differ from distro to distro.
I know what I said. Linux upholds the “don’t break userspace” contract pretty well: most kernels, particularly those from generalistic distros built with modules, are compatible with whatever userspace binaries you throw at them. Major version changes in glibc (or equivalent) is where incompatibilities start, but those happen quite rarely, and you can often still force multiple glibc versions to run side by side.
this will blow your mind
Not really, I’m not new to containers.
This might blow yours though: I once booted up from a Tomsrtbt disk, installed Debian, added some RedHat packages, and topped it up with some pinned downgrades from Ubuntu.
On bare metal, no containers, no rebooting.
How do you do that? First time hearing this
Replace Debian apt sources with Ubuntu ones, do system upgrade and install the Ubuntu-Desktop package, now you have Ubuntu.
It’s been a while since I have done this, but it’s totally possible.
We did this transition from Ubuntu to Debian at Work with thousands of workstations.
It requires a bit of time and testing but it’s possible.
What @[email protected] said. Switching .deb based distros is little more than changing sources, maybe some pinning, doing an upgrade, and optionally a cleanup pass to remove any stranglers.
My main Linux box is a Debian-Ubuntu-Debian upgrade, that hasn’t seen a proper reinstall for like 15 years (switched all the hardware several times, still no clean reinstall).
Switching between non-deb distros is also possible, with a chroot. Like, Gentoo to Fedora. As long as the kernel is compatible with the glibc, it’s basically like running containers, just on slightly hard mode.
Ubuntu has significant differences from Debian so it wouldn’t make much sense to be able to install it as a “flavor” of Debian. However, *Ubuntu are pretty much already metapackages on top of regular Ubuntu. So instead of having different installers for each one, you could just make it an option during install and provide an easy means to add/switch other options later
Yes, if all *ubuntu variants were maintained by Ubuntu maintainers. But since that’s not the case, again, it would be complicated for releasing.
Many distros already offer window manager options when installing, but that’s inside the same distro, not bits and pieces of different distros with possibly different release cycles and dependencies.
One distro may not wish to be “absorbed” by the other.
To be honest, I do not fully understand your question here. Could you rephrase?
They must not replace. If they are merely installing KDE on top of Ubuntu, then theres nothing to do here. The work is already done for us. But if it is doing more than taht, then they should be different packages building on top of the default debian packages for KDE et al.
Sort of like how LunarVim is a distribution of NeoVim. It is the same NeoVim, but with pre-configurations and plugins shipped OOTB, and it can be packaged separately.
Thats the beauty of this. Package managers are already equipped with dependency management. It is far easier to manage dependencies with a package rather than rolling out your own distribution. It is literally one of the biggest reasons why we use package managers to begin with. We dont want dependency hell!
This is a debian specific question, so I will try to answer more generally. It would just have to be done in the same way any package is maintained on that distribution. And this varies by distro; some distributions have different workflows for their package maintenance. The point is that we make use of these already defined workflows that have worked for decades and been iterated on. It is much easier to package than to create a new distribution.
Instead of installing *ubuntu, you install Debian, then run one command:
sudo apt install *ubuntu. I see these as nearly equivalent. Moreover, it could be made to be an option in the distribution’s installer, sort of like EndeavourOS and Fedora do it.That can be what I mean with it being an option in the installer. But if you mean maintaining a whole separate distribution just for this, well … you are maintaining an entirel separate distribution just for this … instead of just maintaining a package.
You fail to realize that each distro is maintained by different people. Your reasoning would make sense if the “core debian” was maintained and packaged by the same people who maintained and packaged *ubuntu.
The end user would download “core debian” from debian, and the *ubuntu “flavor” from *ubuntu. Installing debian then going “apt install kubuntu” wouldn’t work because kubuntu is not in the debian repository.
If debian changed their downloadable “core debian”, it could make it incompatible with what’s in the kubuntu repository. They are not maintained by the same employees of “Linux inc.”
I very well realize this. Packages are maintained by different people too!
The idea is that installing a *ubuntu would literally be the same as installing one of the many packages already available. It works for all those packages, so why wouldn’t it work here?
Yes, that is correct. I apologize if you misunderstood what I said. I did not mean to say that this is the current state. This is what I think how things should be.
Though for the case of kubuntu, it apparently is pretty close. You can in fact already do “apt install kubuntu-desktop”, but you have to be on regular Ubuntu instead of debian. Which is fine, since Ubuntu changes a lot more about debian than just pre installed packages, so it works out for my example.
I do not suggest they should!
When debian maintainers need to release an update of a debian package, they need to make sure it doesn’t break compatibility with … other debian packages - yes maintained by other people. They don’t need to test it with a dozen *ubuntu and other .deb variants, nor coordinate with those other maintainers and wait for them to release their new, compatible versions.
It’s already hard to do that within the same distro.
I am not sure if you are onto something or you don’t understand the proposition. e.g. how does KDE or any other DE developer maintain their packages on debian? Do they not? And its up to debian developers to decide what version of KDE they use? If thats the case then I see your point, which would make it very hard for the so-called “kubuntu” package maintainer, because they have to rely on what debian maintainers do.
Yes, that’s what I mean. For example suppose you had this mixed solution (core comes from debian repository, “kubuntu personality” from kubuntu repository).
Then debian maintainers release updates for their packages - which they tested and validated in systems that use only other debian packages.
Next time you update your system, it may happen that the new version of debian components are no longer compatible with the kubuntu components.
Debian won’t wait for or check if every distro who uses their “core” has tested debian changes and released compatible new packages of their own.
Probably most debian based distros simply repackage many base debian components with minimum or no changes, but they know those releases are compatible with their own “customized” packages, and can have control of their dependencies.
Edit: I didn’t address one of your questions directly: No, developers and maintainers of a linux system component (as kde, and even the kernel) not necessarily are the maintainers of a specific distro packages.
For example, kernel decelopers and maintainers release a new kernel release independent of any distro. It’s up to the distro maintainers to test and package this, then make it available in their repo.
No? do suggest debian kept their install package frozen forever just to make this proposition viable?
Would would they do that? You act as if debian doesn’t already package a massive amount of software, and has no issue adding on to the list.
They test that massive amount of packages to make sure the dependecies and compatibility are kept. They do that between DEBIAN packages. The maintainers of the bash debian package can’t just shove a new release in the repository. It’s tested in DEBIAN systems first.
Who would test this new bash package in every fskcing “addon distro” that installs on top of “core debian” before releasing it to the debian repository? Or would the maintainers of every fscking distro have to scramble to update their packages after debian released this, and users have updated, breaking compatibility with the “addon” packages?
Or the opposite, the “addon” distro package developers want to use a new feature from a library, but can’t, because debian hasn’t updated their packaged version yet.
youre over complicating it. Debian adds new packages to its repository all the time, and this would be just one more package they add. Simple as that.
ha, so you don’t mean having multiple distros dropping their “base systems” and only providing the “addon” part in their repos, but actually having the “core” distro include all the “addon” flavors into their repo. haha really, really “simple”.
“Hey debian, I’m a one man operation out from North Korea, and I made this customization package. I swear it complies with every privacy and security policies, and that it is compatible with your core system. No it won’t break anything. Can you please include it in your repo?”