I am curious how Ubuntu Mate first 'master' instance is made?
Let's put aside rebranding, building installer ISO, creating infrastructure for distro support, etc.
What are steps leading from upstream Ubuntu to Ubuntu Mate? Is that Ubuntu Server with Mate DE on top of it? Is that Ubuntu with Gnome DE purged and Mate DE installed? Anything else?
I'm not sure what you're actually asking, and anyway as I'm not a developer the moment details get technical it can quickly get beyond my own knowledge anyway. Either way, I'll provide some thoughts that maybe helpful.
Ubuntu and flavors are built from packages; Ubuntu Desktop/Server & base products are made using packages from the main repository; where as Ubuntu's community flavors (Ubuntu MATE etc) include packages from the community repository which is universe. Each flavors work is really put into these packages.
What packages get included on ISOs can be found from looking at seed files; used by the build infrastructure, so if you want to compare Ubuntu Desktop, Ubuntu Server, Ubuntu-MATE or any other flavor I'd contrast the seed files, which are used by the same build infrastructure for Ubuntu and all flavors. The difference between them is mostly just packages included.
For Ubuntu MATE's last release (25.04 or plucky) you can explore here - Index of /seeds/ubuntu-mate.plucky Exploring from that link to compare with other flavors, Ubuntu Desktop, Ubuntu Server, even other releases shouldn't be difficult.
If you pick an seed such as desktop, the most important package (at least in my opinion) will be
* ubuntu-mate-desktop # metapackage for everything here
though that isn't complete of course; ie. ubuntu-mate-guide will of course be important to some users & its these extra inclusions that make Ubuntu MATE special which I've ignored here.
As a key aim of Ubuntu is keeping the delta (difference) between Ubuntu and upstream (Debian sid) as small as possible, a lot of Ubuntu developers (who are also often Debian maintainers/developers (DM/DD)) often commit changes upstream to Debian sid which is then imported into Ubuntu development when of course imports are happening (either Ubuntu or Debian isn't in a freeze state). This applies to Ubuntu and flavors too.
If changes made by Ubuntu devs (inc. flavors) are done at the Ubuntu repository level, its done within packages that highlight it's a Ubuntu package; easily seen in the ubuntu-mate-desktop and ubuntu-mate-guide package names I've already mentioned, ie. its clear they've not been pushed upstream into Debian sid.
Hopefully something of this was useful.
Thank you for discussion. Now I'm well aware that UM installer image is automagically built according to a set of configuration instructions including 'seeds'.
I supposed that before giving a spin off a distribution flavour one had to build its prototype manually. Well, not as much as build but reconfigure upstream distribution installed. It is interesting what must be the base installed and which manual actions convert the basic Ubuntu into Ubuntu Mate.
I recall the history of Ubuntu MATE and how it got off the ground being described by both Martin Wimpress and Alan Pope on podcast (three different ones too if I recall accurately), one at least was on the old Ubuntu Podcast (UK maybe too at the time; I forget; Martin wasn't a host for the show at the time), but as my memory of those podcasts was a long time ago (decade ago) I'd re-listen for clues.
Details can be found here - History | Ubuntu MATE
Martin also spoke about differences of creating the Ubuntu MATE ISOs on a machine 'under his desk' (if I recall correctly; when Ubuntu MATE was a spin), and differences when Ubuntu MATE became an official flavor.
If I wanted to know more, I'd possibly chase up these podcasts and listen again. They were all ~months to a year+ after the actual events, so the actual event provides some timeline on when to look. There were many of them as different podcasts had Martin as guest & similar story/questions were asked.
Again, if interested, you could contrast with other recent flavors (Ubuntu Cinnamon, Ubuntu Unity etc), or if you wanted to contrast with non-Ubuntu's, I recall enjoying & learning from Jacque Raymer who talked/blogged when Makulu Linux switched from using a Debian base to a Ubuntu base, and on how Makulu Linux ISOs were created, and changes made to the (ISO creating) scripts Jacque's used & why. ie. I'd start by reading blogs, or listening to podcasts from various people who've created their own spin. There are many more than I've mentioned too.
If you are looking to know how UbuntuMATE was built, when it was "born" from the original concept, if you can understand it, I believe you will find all the nitty-gritty details in
If you are looking to see how the UbuntuMATE distro is put together today ...
I don't understand the references being used, but it so
unds like the files in
would be the prime indicators as to what is being done.
From what I saw from scanning some of the files, it seems like there is no "merging" with any "shared core" directly, possibly only ongoing updates to what might constitute that shared core, along with the various patch submissions for the fixes or additions to the UM-specific MATE-related code.
At least that is what I get from it.
Maybe a Distro developer (daily build operator?) could pipe in to offer enlightenment to the flock of UM adherents! ![]()
daily-brew/.github/workflows at main · ubuntu-mate/daily-brew
The "daily brew" has nothing to do with it. It was an incomplete attempt at building the software on a schedule with the potential to upload to a PPA and know if a build fails. A little bit like a "rolling release" of packages for Ubuntu MATE developers. It's abandoned now.
I imagine the start of a Debian-based distro starts with debootstrap, which extracts the base files /bin, /lib, /usr, /etc. With a minimal base filesystem, then it's pretty much installing the packages, chroot style. Basic utilities like bash, nano, apt, but also things like the kernel, bootloader, libraries for networking, disks etc.
It'll be a separate process to create a "squashfs" image and build a bootable ISO. The Arch Linux 32 i486 (2022.12.01) CD is interesting/different, because the whole filesystem (/bin, /etc) is literally on the CD, read-only style (for low RAM PCs).
I learnt a bit from getting Arch Linux working in WSL (before it was officially an option) and building a custom ISO with archiso some years ago. It doesn't seem as complicated, since the concept of a base system, chrooting and "everything is a file" means it is possible to use run completely different distros
on the same machine using containerisation tools like Docker. ![]()
If we were to go even further "from literally scratch", how do Debian/Ubuntu create the bootstrap?
No idea, but compilers would need compiling, to compile everything else.
Now, I don't actually know what system Ubuntu uses to generate images from scratch, but I imagine it'll be automated scripts, and the seeds per flavour as mentioned earlier.
Ubuntu MATE Remix ISO?
I'm not sure if Martin ever uploaded the script(s) that created the unofficial remix ISOs, or the PowerPC port. There is the Raspberry Pi build script, which might be more complex since it builds an image for a different architecture.
These could serve as an interesting one to study if they can be found.
Experiment
If you're wanting to play with the idea, you could mess with a lightweight distro like Arch Linux, since it's pretty well documented. Package wise, it starts with base depending on 28 packages - one of which is the filesystem, and the coreutils (see file list, it's the bare essentials like ls, echo, tty)
... or to stay within the Ubuntu world, bootstrap into a directory and chroot into it. I imagine it'll be like "Ubuntu Server" but extremely barebones. It has similar essentials provided in packages like base-files and coreutils
Thank you, Luke, for that background info. If it had been flagged as "frozen" or "archived", I would not have offered that as an avenue to pursue.
Thanks again, Luke! Lots of good info there! I will have to set aside some time to look into all of that ... properly! ![]()