Bulding a whole Linux distribution is a major task. Maintaining it, keeping critical packages up-to-date is even harder. If I had to do it all from scratch, I would probably not even start. However, there are some shortcuts.
The first problem is: which packages are required, how to strat building it all up? In otherwords, bootstrapping an userspace. Fortunately this doesn't need to be done from scratch anymore: there are existing distributions I could look at and figure which packages are needed at minimum.
I am using Debian for this, whcih also means I can donwload the original (unpatched, verified) upstream release tarballs all from the same place, using apt-get source (which delivers it as *orig.xz). This saves a lot of time.
Downloading and compiling a piece of software is typically not very hard.
Figuring the ./configure options takes a bit more time, especially if there are tricky aspects. Debian comes to the rescue again: I strat by looking at their ./configure line. Then I add a lot more, typically disabling non-essential features (such as nls).
A much harder part is when some software is too old or too new so they don't compile out of the box or don't play well with widely accepted standards. These kind of problems are solved by packaging patches. Fortunately I don't need to produce these alone: I can copy the relevant ones from Debian.
Another hard problem long term is how to keep packages up to date. How to figure when there's a relevant new version, when there's a critical patch e.g. for fixing a security issue.
The answer is yet again "outsourcing" this to Debian: there is a virtual mapping between the vast majority of conj package sources and Debian package sources. For example there is a conj package for bash and Debian also has a package for bash. There are a lot more packagers dealing with those packages at Debian and they are good at figuring when those packages need to be updated or patched.
All I need to do is run a script from a crontab that keeps track on Debian package changes (of the relevant packages) and mail me a summary when there's a new version. Then I can decide if I need to rush and roll a new package, again using Debian's work to figure the new patches.
There are some bloatware that I occassionally need to use, for example a web2.0 GUI browser or gimp. Packaging these few software and all their dependencies would cost more effort than producing and maintaining the rest of the distro. On the other hand it is not realistic that I could do any of the conj magic to get these badly designed software work better.
However, I need these software only one a few of my systems: majority of my installations, servers, virtual machines, embedded systems, won't ever need to run them. Plus where I typically need to run them are powerful x86_64 machines.
The approach on this is that I won't package them. Instead I quarantine them. I will package qemu with KVM support, then I can install and run a bloated Linux distro within qemu and install the few bloatwares I need to use in there. Finally I set up some helper scripts so that on my host conj system's X "desktop" the integration is seamless:
As a bonus I can make a snapshot of the qemu image before I do an upgrade the bloatware so if anything important breaks in the upgrade I can roll back. As a user most probably I'll install Devuan in that qemu image.
Conj is not a Debian based distro, bacause:
But conj is a distro based on Debian in the sense: