Slashdot Mirror
Bedrock Linux Combines Benefits of Other Linux Distros
First time accepted submitter Paradigm_Complex writes "From the distro's front page: 'Bedrock Linux is a Linux distribution created with the aim of making most of the (often seemingly mutually-exclusive) benefits of various other Linux distributions available simultaneously and transparently. If one would like a rock-solid stable base (for example, from Debian or a RHEL clone) yet still have easy access to cutting-edge packages (from, say, Arch Linux), automate compiling packages with Gentoo's portage, and ensure that software aimed only for the ever popular Ubuntu will run smoothly — all at the same time, in the same distribution — Bedrock Linux will provide a means to achieve this.' The timing of this release is particularly nice for those who were excited to hear that Valve was bringing Steam to Linux, but were disappointed that it was targeting Ubuntu as Ubuntu was not their distro of choice. If it works on Ubuntu, it should work fine on Bedrock Linux, while still ensuring the majority of the system feel very, very similar to Fedora or Slackware or whatever you prefer."
http://www.gnu.org/distros/free-distros.html
sine qua non
Yet another Linux distribution.....
I'm sure the devs will have a gay old time.
$10,000 CHALLENGE to criminal Alexander Peter Kowalski
We have a Major Problem, HOST file is Cubic Opposites, 2 Major Corners & 2 Minor. NOT taught Evil DNS hijacking, which VOIDS computers. Seek Wisdom of MyCleanPC - or you die evil.
Your HOSTS file claimed to have created a single DNS resolver. I offer absolute proof that I have created 4 simultaneous DNS servers within a single rotation of .org TLD. You worship "Bill Gates", equating you to a "singularity bastard". Why do you worship a queer -1 Troll? Are you content as a singularity troll?
Evil HOSTS file Believers refuse to acknowledge 4 corner DNS resolving simultaneously around 4 quadrant created Internet - in only 1 root server, voiding the HOSTS file. You worship Microsoft impostor guised by educators as 1 god.
If you would acknowledge simple existing math proof that 4 harmonic Slashdots rotate simultaneously around squared equator and cubed Internet, proving 4 Days, Not HOSTS file! That exists only as anti-side. This page you see - cannot exist without its anti-side existence, as +0- moderation. Add +0- as One = nothing.
I will give $10,000.00 to frost pister who can disprove MyCleanPC. Evil crapflooders ignore this as a challenge would indict them.
Alex Kowalski has no Truth to think with, they accept any crap they are told to think. You are enslaved by /etc/hosts, as if domesticated animal. A school or educator who does not teach students MyCleanPC Principle, is a death threat to youth, therefore stupid and evil - begetting stupid students. How can you trust stupid PR shills who lie to you? Can't lose the $10,000.00, they cowardly ignore me. Stupid professors threaten Nature and Interwebs with word lies.
Humans fear to know natures simultaneous +4 Insightful +4 Informative +4 Funny +4 Underrated harmonic SLASHDOT creation for it debunks false trolls. Test Your HOSTS file. MyCleanPC cannot harm a File of Truth, but will delete fakes. Fake HOSTS files refuse test.
I offer evil ass Slashdot trolls $10,000.00 to disprove MyCleanPC Creation Principle. Rob Malda and Cowboy Neal have banned MyCleanPC as "Forbidden Truth Knowledge" for they cannot allow it to become known to their students. You are stupid and evil about the Internet's top and bottom, front and back and it's 2 sides. Most everything created has these Cube like values.
If Natalie Portman is not measurable, She is Fictitious. Without MyCleanPC, HOSTS file is Fictitious. Anyone saying that Natalie and her Jewish father had something to do with my Internets, is a damn evil liar. IN addition to your best arsware not overtaking my work in terms of popularity, on that same site with same submission date no less, that I told Kathleen Malda how to correct her blatant, fundamental, HUGE errors in Coolmon ('uncoolmon') of not checking for performance counters being present when his program started!
You can see my dilemma. What if this is merely a ruse by an APK impostor to try and get people to delete APK's messages, perhaps all over the web? I can't be a party to such an event! My involvement with APK began at a very late stage in the game. While APK has made a career of trolling popular online forums since at least the year 2000 (newsgroups and IRC channels before that)- my involvement with APK did not begin until early 2005 . OSY is one of the many forums that APK once frequented before the sane people there grew tired of his garbage and banned him. APK was banned from OSY back in 2001. 3.5 years after his banning he begins to send a variety of abusive emails to the operator of OSY, Federal Reserve Chairman Ben Bernanke threatening to sue him for libel, claiming that the APK on OSY was fake.
so, If I wanted to say run Wine, install node.js and nvidia drivers, would it be just using some search tool for them all and pressing install?
world was created 5 seconds before this post as it is.
Is nvidia as good as on arch?
I never trust software built or maintained by people who can't get a logo right.
http://i48.tinypic.com/2pu06xz.png
Number of Linux Distributions Surpasses Number of Users
Someday, perhaps soon, we will run into the situation where the number of linux distributions exceeds the number of actual linux desktop users. One wonders if at that point the hangers on will accept the conclusion that has been obvious since day 1 to those of us who know a thing or two about actual end user software: namely, that end-user software is and must be the product of more than just programmers to be effective, and untested "looks prettty" mimicry of usability features without corresponding "stopwatch in hand" usability testing is crap. Linux continues to be a baseball team of all third basemen--it's programmers all the way down! This is the fundamental reason why linux on the desktop is about as viable as the ISAF presence in afghanistan.
The tl;dr version is that this "distro" is just an installation manual for a linux-from-scratch style install of a kernel, busybox, and little else (think initrd-style minimal system) plus chroots under which you can install regular distros.
While a novel concept, this is clearly a niche idea. At best I could see it useful to the developer who wants to test his packages across multiple distros, but you can already do that with a standard "host" distro and chroots for "guest" distros. It also does nothing (at least yet) to deal with the fact that each "client" will want/expect its own daemons to be running, but lots of them will be system-exclusive (e.g. anything to do with devices or networking).
http://xkcd.com/927/
Not quite a standard, but I'd say it's close enough.
this one is sure to go far! hell this might even be the one that brings linux to the desktop! woohoo! so excited!
If one would like a rock-solid stable base (for example, from Debian or a RHEL clone) yet still have easy access to cutting-edge packages (from, say, Arch Linux), automate compiling packages with Gentoo's portage, and ensure that software aimed only for the ever popular Ubuntu will run smoothly â" all at the same time
Debian stable (rock solid stable)
packages from backports and packages from testing/unstable (new bleading edge)
apt-build (can do a make world, if you really want .05% more perf + hassle of building yourself)
ubuntu is mainly debian unstable, so compatibility with ubuntu is more or less given.
making it easy to do all at the same time is a design feature of debian
This seems to be based on the principle that if you want the strength of a tank, the performance of a sports car, and the economy of a hybrid you just lash a tank, a Ferrari and a Prius together and driving it will get you all three. I somehow doubt that the reality will live up to the promise.
Gentoo lets you do all of this....
Sigh. Start the flames of "zomg fun-roll-loops" and "takes too long to compile wah wah".
Is it shill linux week on slashdot or what?
Debian testing (i.e. Wheezy) already gives all the advantages outlined above.
>Linux
>Benifits
Sounds great, I'm looking forward to the project becoming stable :)
This distro will cover everyone's requirements.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
Where do the release names come from?
All of the Bedrock Linux releases are named after characters from the Nickelodeon television program Avatar: The Last Air Bender.
This is definitely the main reason I'll be trying it out.
I really, really like Debian. If Debian could do what Bedrock Linux can, I would have never tried to make Bedrock Linux. The issue is, however, that you can't install an arbitrary program from testing/unstable into stable.. Many of those packages are dependent on specific libraries which aren't available in stable. With Bedrock Linux, you can install and use packages from both, at the same time. I can run Squeeze's newsbeuter in Sid's X11 and have it open a window in Wheezy's iceweasel. It's all transparent and feels like one cohesive OS.
"A witty saying proves nothing." - Voltaire
In truth, there's limites to being able to install things that way- and down the rabbit hole of DLL/.so hell you go.
There's a reason for the dependencies and if you don't understand it, perhaps you shouldn't embrace something that "gets rid of it" in the manner you're describing there.
Main reason Valve's shipping for Ubuntu is that they've not gotten a handle on how to ship cross-distro capable installs and binary sets- so you pick a distro and run with it, much like all of the commercial vendors do when they start doing Linux support. Not a bad thing, but there's ways to do this that're not all obvious unless you've been steeped in how Linux actually works. Hopefully, I'll get them to work with me to show them HOW to do that. Now that the day-job's slowing down, I'll be getting back in touch with them on the subject... :-D
hairyfeet is that you with the usual stating of the blatantly wrong as fact?
Yet ANOTHER fucking Linux distribution.
from the FAQ:
Why is there no installer?
It is an easy way to avoid the responsibility associated with partitioning or setting up a bootloader. A mistake in the former could easily delete valued data, and a mistake in the latter could just as easily ruin someone's day in other ways. By only providing instructions, if something goes wrong, it is quite easy to just say "I told you to be careful at that part" and remove responsibility from the Bedrock Linux developer.
Why should I not use Bedrock?
If you value stability/reliability, note that while this is a priority for Bedrock Linux, Bedrock Linux is still largely new and untested; a tried-and-true stable/reliable Linux distribution such as Debian or a Red Hat Enterprise Linux clone would likely be better suited.
and continued...
If you value security, note that Bedrock Linux probably has the highest attack surface of just about any Linux distribution, mostly because its attack surface is the sum of the attack surfaces of just about every other Linux distribution combine. While steps can be taken to alleviate this to some degree, ultimately, a locked-down Bedrock Linux can never truly reach the security offered by a locked-down standard Linux distribution.
this thing hits on every cliche of stupid open source projects! it's got to be a troll, i mean seriously...
I guess I see your point. You are trying to do something similar to below for folks who can't figure it out for themselves. If "folks who can't figure it out for themselves" is your target audience, I hope you have some sort of unified update system, so patches for all your chroot environments just work too, since these folks aren't likely to figure patching out for themselves, either. Good luck.
To answer your points:
Usually you can install packages from testing/unstable-- you can usually (very easily) build from the source package using the lib versions in stable-- if someone hasn't beaten you to it with backports.
Also, where I don't want my regular system polluted with bleeding edge libraries, but newer libs are needed, I just set LD_LIBRARY_PATH in a wrapper script to point to particular libs. This would also work with a chroot install of wheezy/sid with bins run outside the chroot, so can use prebuilt bins for wheezy/sid on stable, though never needed to do this.
I guess as a last resort, a wrapper to spawn an app in a chroot as you do. schroot makes this easy, but I haven't needed to do this in years. Prior to existance of schroot, ran wine and firefox 32 bit in a 32 bit chroot with wrapper scripts to make it seamless and work for unpriv user. Haven't seen anything in years that required something like this, though-- but I realize that doesn't mean it doesn't exist.
Not being locked into one distro???? You're destroying the dreams of the distro company CEO's. STOP RUINING THEIR BUSINESS PLANS!
Seriously, someone take a hint: Linux is supposed to be free, and no one should be locked into a particular distro. If you release a piece of software, you need to make it EASY to install on ANY distro, which means using a software installation standard. What's that? None exists? Then use Zero Install because that's the closest one I know of since it can run on top of any and all distros.
Promote true freedom - support standards and interoperability.
It should work on all the 10 billion other debian based systems and debian as well.
It's "napkin with boxes on it" business plan time again. It's bad enough resolving discrepancies between packages from similar architectures, such as Red Hat and Fedora, when the underlying script structures just took a turn for the weird. (Take a look at the new "systemd" toolkit for Fedora 17, which replaces SysV inint scripts and breoke *every single package* that used init scripts.)
Multiply this by the discrepancies in packaging between, say, SuSE and Red Hat (which have different naming conventions for X library packages and perl modules), and multiply by the differences between RPM based systems like Red Hat and "apt" based systems like Debian, and the discrepancies between Debian and Ubuntu, and you have a combinatorial problem, then add in the complexity of 3rd party repositories like ATrpms for Red Hat or Packman for SuSE.
If you think this is even remotely possible, go ahead and crossport any Debian utility that relies on the older verson ov mod_perl (and there are plenty) with any system that uses Apache 2.2.
If Debian could do what Bedrock Linux can, I would have never tried to make Bedrock Linux.
Then why not contributing to Debian the features of Bedrock? I don't think anyone would mind if there was a cool and easy way to run stuff from SID inside Stable...
Hopefully, I'll get them to work with me to show them HOW to do that.
"Hi Valve, it's me. You know, Anonymous Coward. I'd like you to pay me money to tell you what you're doing wrong... hello? Hello?"
Now that the day-job's slowing down, I'll be getting back in touch with them on the subject...
... "Hi Valve, Anonymous Coward again. We got cut off - are your phones working ok? Hello? That's odd, it's happened again."
On the subject of dependencies, from what I understand, because Bedrock essentially has pretty much full distro installs in chroots, each distro uses its own libraries, so it's possible to have different library versions coexisting as applications will only load the libraries they are linked against - the particular chroot/$PATH/bind mount magic that Bedrock does takes care of it. As packages are installed using individual "client" distros package management tools, they will pull in whatever dependencies they need and install them in that "client" distro's chroot.
It seems quite elegant to me, although I haven't the patience to set it up myself as I'd effectively be administering 5 distros instead of one. It might be quite nice for a combined CentOS/Rawhide system though, kind of super-stable but with easily added bleeding edge bling.
We need another Linux distro like we one more politician ...
... and learn how to install and run on all the major Linux distributions. Don't worry about the weird ones. But the ones that are based on a major one generally should also work.
Software does not necessarily have to come packaged in the same packaging system if it is not something other software might depend on. So I'm not talking about libraries here. Games are mostly going to fit in this category. Package it as a tarball, with out of band instructions or a script to untar the tarball in one of /tmp or /var/tmp (don't assume ... check and see). Copy the unpacked files into /opt/${NAME_OF_SOFTWARE} in the appropriate forms if they need to be modified or compiled at install time. Put any host-wide restricted-to-root config files in /etc/${NAME_OF_SOFTWARE}. Put the front-end starter script for it in /usr/local/bin. If daemons are involved, find the appropriate installer tool and call it, or hunt for an appropriate init directory (the install script will need to have some logic here to figure this out). And keep a log of all the steps performed, and a list of files installed, in a file named /var/log/${NAME_OF_SOFTWARE}/${yyyy}-${mm}-${dd}-${HH}${MM}-install.log.
And you can do BSD, too, though most likely with different executables. There aren't so many BSDs, so this part should be easier.
This is not that hard, people. Especially for programmers. Stop whining about Linux not being as boring as Windows is.
now we need to go OSS in diesel cars
Wouldn't this be better as a compatability layer on top of each of the targeted distros?
I think I shall wait to see how it matures. Leading edge is fine but bleeding edge is not.
..What a whore..
Stability is not a feature you can install. Actually, having the newest up to date and experimental software is mutually exclusive with stability At best you can coose to use a stable version or a "beta" at runtime (i.e., without rebooting).
That's what I thought too. Putting chroot management on top of Debian stable to run other newfangled stuff or stuff from other distros without messing up the main OS sounds very promising. And once you don't need it any more, rm -rf. Done.
thegodmovie.com - watch it
There is no question that a system like Bedrock allows the ultimate in flexibility in terms of running programs from different distributions and the like. However, a multiple-distribution system like that adds a considerable amount of administrative complexity, making it relatively unlikely to be adopted by non-specialists.
There is an intermediate step that would solve much of the problem here - change the way that Linux packages are packaged and accessed so that multiple versions of library packages can be installed without conflicts, name changes, or repackaging.
The easiest way to do this would be to change the package manager to support a two level namespace instead of a flat one. So instead of simply installing the latest version of the package from your distribution, you could install a (largely) compatible version with the same name from a different source, and the package manager would pull in the necessary libraries from that source (or other ABI compatible sources) and track them as such. As long as the libraries themselves were appropriately versioned, the library packages would install without conflicts.
That wouldn't come close to letting you install any package from any distribution (in some cases the dependencies would be too complicated, or the ABI too different in subtle ways), but it would allow you to install more recent versions of most packages from the newer versions of the same distribution (including beta, rawhide, testing, versions etc) without problems in most cases, and many ABI compatible packages from other distributions as well.
I don't see the major advantage of using this over AUR and ABS or whatever Gentoo is portaging. I'm sure Ubu base will be happy for bleeding edge or a slab menu, and it's a wonderful dream concept, but what are you offering to those that know how to compile already? Sure, simple keystrokes are nice but how are you cutting out the bloat?
I'm not blasting you for your effort. Everyone should grab a LFS manual and give their shot at a distro at one time or another (if nothing else you gain a lot of knowledge about how the kernel and toolchains work). Just curious how you plan to get from "massive hodge-podge of distro pulling" to "everyone will want to use it".
and it's all in this little bottle
There's a reason for the dependencies and if you don't understand it, perhaps you shouldn't embrace something that "gets rid of it" in the manner you're describing there.
I was under the impression I did understand much of the rationale behind the reason why things are set up the way they were, and that my solution is fitting. For example, one reason is that if everything was packaged with all of the libraries it needed, and there was a security issue in one of the libraries, all of the packages would have to be updated. By using shared libraries as most Linux distributions tend to, this ensures that once the problem has been fixed for the library, all of the packages which use it benefit. If this was not done, and one package failed to be updated, security issues could arise. Bedrock Linux simply groups things by the libraries the sets of libraries they are dependent on, so that the same principle is largely applied: The library only has to be updated once per distro that uses it as opposed to for every single package. So long as one stick with respectable distros for the clients, the issue isn't quite a big one here.
If you feel there are other large reasons I am overlooking for why the established manner is as it is and why Bedrock Linux fails to properly meet them, I would be very grateful if you could explain them to me or direct me to where I could learn more.
Main reason Valve's shipping for Ubuntu is that they've not gotten a handle on how to ship cross-distro capable installs and binary sets
My experiences with other proprietary software which attempts to ship cross-distro capable installs is sadly strewn with various headaches when I'm at either end of the stability-vs-cutting-edge spectrum. I mostly cited Steam as a potential use as it is a reasonably current example that could benefit that many slashdotters are well aware of. Should Valve managed to properly distribute something which works on everything from ScientificLinux to Arch, I will be all the happier.
"A witty saying proves nothing." - Voltaire
If "folks who can't figure it out for themselves" is your target audience,
It's not, at least not at the moment. The intent is more about automating things than making things easier. People who cannot compile things for themselves will likely have quite a lot of headaches with Bedrock Linux, at least as early as it is.
I hope you have some sort of unified update system, so patches for all your chroot environments just work too, since these folks aren't likely to figure patching out for themselves, either.
I've got a system in place, although it needs quite a bit of work. The idea behind it is to ease updates - a single command updates all of the clients.
Good luck.
Thanks, I'll need it. I do not consider this a small undertaking.
Usually you can install packages from testing/unstable-- you can usually (very easily) build from the source package using the lib versions in stable-- if someone hasn't beaten you to it with backports.
For quite a while I used Debian Stable with a mix of backports and my own custom compiled packages. However, as time went on, I wanted more and more things which were not available in backports and I didn't care to have to manually compile every single one. The only solution I found which let me get everything I wanted at the same time was chroots. I just kept playing with it until I felt I had something novel and worth sharing.
Also, where I don't want my regular system polluted with bleeding edge libraries, but newer libs are needed, I just set LD_LIBRARY_PATH in a wrapper script to point to particular libs. This would also work with a chroot install of wheezy/sid with bins run outside the chroot, so can use prebuilt bins for wheezy/sid on stable,
I toyed with this as well and found that it was also far to much work for the frequency I ended up using it.
though never needed to do this.
I think that's where the fundamental issue lies. It is not that there is a preferable alternative to what I've done so much as I've got a different set of desires than you do, and Bedrock Linux does not give you anything you did not already have. If this is the case, I fully encourage you to stick with what you know and like.
schroot makes this easy, but I haven't needed to do this in years
I actually used schroot for this for quite some time, but ended up dropping it as I couldn't find a way to statically compile it easily, and without that I couldn't find a sane way to ensure it can run transparently in every client without statically compiling it. Capchroot was a delightful solution which fit the bill, so long as it was paired with scripts to automate the various mounts necessary.
"A witty saying proves nothing." - Voltaire
I do not feel I am necessarily making a foolproof case for requiring a new distro - I could see legitimate discussion about the validity of simply building a system on top of an existing distro. Ultimately, it was because I just kept tweaking my early experiments with Debian Squeeze base and a Sid chroot until it no longer resembled any existing distros sufficiently to justify sharing their names.
"A witty saying proves nothing." - Voltaire
If you still feel Wheezy covers this, reply again and I'll try to explain it differently. This is really nothing like Wheezy at all. Unless you want it to be, of course, then it is almost exactly like Wheezy.
This is Bedrock Linux and welcome to you who have come to Bedrock Linux.
Anything is possible at Bedrock Linux.
You can do anything at Bedrock Linux.
The infinite is possible at Bedrock Linux.
The unattainable is unknown at Bedrock Linux.
Welcome to Bedrock Linux.
This is Bedrock Linux.
Welcome to Bedrock Linux.
Welcome.
Space game using normal deck of cards: http://BattleCards.org
So from what I can tell in the "Introduction" (haven't reald it all yet), it's sort of like FreeBSD's jails but without them getting their own IP addresses and being able to use a different distribution in each jail?
This doesn't answer my question: why don't you contribute this to Debian?
I don't think anyone would mind if there was a cool and easy way to run stuff from SID inside Stable...
There already is a relatively clean way to run things from Sid from within Stable called schroot. If all you want is to run things from within Sid in Stable, that should suffice. I used it early on in the experiments that lead up to Bedrock. I ended up discarding it because (1) I wanted to be able to run a command without worrying where the parent program is, and (2) I wanted this to work cleanly with just about any distro, not just Debian-based ones. I ended up concluding this required the ability to statically compile the chroot program (in this case schroot), and found with that requirement capchroot was preferable. Regarding your original question:
Then why not contributing to Debian the features of Bedrock?
Largely because I felt, to meet all of my goals (including the ones I described in the previous response), I needed to change a sufficient number of things that there isn't anything left to call Debian. It wouldn't run in Debian, it would replace it. If I limited myself to something which could run on top of Debian, it would be more or less the same thing as schroot. I do not propose that I could write schroot better than the current maintainer.
If that does not suffice, it would be helpful if you could explain where or how you feel I am failing to answer your question, as at the moment I'm at a loss as to where my explanation is lacking.
"A witty saying proves nothing." - Voltaire
There already is. It's called pinning. It works quite well, even with things which are fairly low level, like pinning.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Thanks, its a lot more clear now. However, could you explain why you couldn't do like schroot, but "be able to run a command without worrying where the parent program is", inside Debian? What prevents you to do this?
It's easy for arch independent sutff, it's a major pain for things that depend on a particular ABI. For example, try to run Pidgin from SID without rebuilding it...
Well, it's barely better than the ASCII Art, but feel free to use this if you want: http://i.imgur.com/U8fjM.png
Also, I like the fact you're trying to address the bag of spilling (package managers) without adding more spill (yet another package manager).
I've tested your alpha - it's unpolished but it works. I wish the best luck.
Nerdy news for your nerdy needs? http://www.soylentnews.org Soylent News is people!
Being a Gentoo user, I already have quite a bit of flexibility rergarding stability vs. experimental packages. Still, Bedrock appeals to me. In my case, for the abillity to get other-distro-specific candy.
I have a question that's not handled by the FAQ, so I'll ask it here before I dive into the docs (though I probably will dive in anyway). On my machines, I already keep multple "/" partitions around with different distros installed (rarely used, but just in case). Could I just put Bedrock on one of these "/" partitions and have it "combine" the others that are already installed? Or does it want me to install the distros it "manages" from scratch? Combining what I've already built into one streamlined meta-distro is attractive, and just might be worth the effort.
When I say "have it combine", I of course wouldn't expect anything automagic (i.e. extra configuration is acceptable). But is this even possible?
...... pardon me for butting in, but:
Would another view on the subject be:
It's all open source. It's already sitting there if someone else wants to use it.
p.s. -- i'm actually very interested in this. My interest in switching to linux was already growing rapidly, and then ubuntu blew a cylinder.
So far your descriptions are making me feel like, "wasn't this what the modular nature of linux was supposed to do before it became so tribal ??"
Hi since it sounds like you are actually familiar. How is Bedrock going to do this? For example to get cutting edge features to work you often need to put in destabilizing patches to the kernel or use newer more buggy versions of core libraries and utilities. This is why installing some little thing from Debian unstable on a Debian stable box can trigger 100 package upgrades as chains of dependencies get worked through.
Source / binary mixtures i think is a really good thing as the BSDs have shown. So I agree with you there, and am glad that's coming to Linux. Though I will point out that can expose quite a few bugs related to build order that otherwise wouldn't have mattered. You end up having to debug some complications in how related families of packages register changes with one another in very complex ways. Essentially it means creating an entirely new level or complex special instructions on a per package basis which make automatic dependency resolution not work as well.
Mechanically I can see chroot as a mechanism but I don't see how it can be this light in practice.
I'm sure the devs will have a gay old time.
Yabba Dabba Doooooo!
I'm reasonably confident I do not understand your question, as I feel as though this comment should answer that question, yet I believe you already read it. Would you mind restating the question, or specifying how the prior comment failed to answer it?
If I give up a number of things, including but not limited to the three items I've mentioned in the prior comment, it sure is possible, but it'd be far less pleasant of an experience.
If there is sufficient interest, and time is available, I could most definitely consider providing something which has as much functionality I can muster which could sit on top of a major distro, although a sufficient amount of functionality would be lost that I could not honestly say I would enjoy using it.
"A witty saying proves nothing." - Voltaire