<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Timothy Butler wrote:
<blockquote cite="mid:5423A793-D42B-4780-B53E-7C3E9C3B0A57@ofb.biz"
type="cite">
<blockquote type="cite"><br>
And I think RH and deb support belongs in chroot jails. That should
reduce the hosery by a lot.
<br>
</blockquote>
<br>
How would you maintain compatibility with packages? Especially
those that list various system libraries as dependencies?
<br>
</blockquote>
This is why the per-supported-package-type chroot jail tends to make
sense. RH and Deb packages do not actually list system libraries as
dependencies, unless they are very nastily bug-ridden: they list
system library packages, instead. So that's fine. If people need
their favorite RH RPM installed for XYZ, the RPM tool they are using
will ask for the libXYZ RPM, which they will also have to install,
which will go into the same chroot.<br>
<blockquote cite="mid:5423A793-D42B-4780-B53E-7C3E9C3B0A57@ofb.biz"
type="cite">
<blockquote type="cite">Ah. This reminds me of an idea some people
tried in a distro years ago, long defunct I think. They didn't prefer
/usr/bin, /usr/lib, /usr/share at all. They had something like
/OpenOffice, and /Firefox, et cetera, a completely revamped filesystem
tree. The problem was no source was written for the new filesystem
tree; the problem was solved, reportedly, by a dense forest of symbolic
links. I think that if rpm's and deb's are supported in chroot jails,
we come as close as possible to (a) avoiding the symlink-forest problem
and (b) supporting existing standards.
<br>
</blockquote>
<br>
Yes, I think you are right. I seem to remember that.
<br>
</blockquote>
Ed H. recently pointed me to another similar, and sadly similarly
defunct, project, ROXOS. It seems to have died aborning in 2004 or
so. But the ROX desktop looks like a very interesting
filesystem/desktop/WM toolset, possibly fully functional; worth
checking.<br>
<br>
<a class="moz-txt-link-freetext" href="http://roscidus.com/desktop/ROX-All">http://roscidus.com/desktop/ROX-All</a><br>
<blockquote cite="mid:5423A793-D42B-4780-B53E-7C3E9C3B0A57@ofb.biz"
type="cite">
<blockquote type="cite"><br>
But the point is that the distro itself doesn't depend on the .pac
system. The distro uses much larger sets. A single large set is far,
far easier to debug than five hundred packages half of which may or may
not be present, and half of which may have been installed in many
different orders.
<br>
</blockquote>
<br>
Would the contents still be assigned to "fake" packages so the
package manager knew what was installed?
<br>
</blockquote>
Not usually :-) If a sysadmin installed an RPM for ABC, all related
RPMs would have to be installed as well. There might be simulation
RPMs needed, for kernel dependencies. In general, though, I want the
RPMs to either require the real dependency RPMs they are used to, or to
be considered broken in this OS. It reduces bug-vectors, and raises
the bar of reliability in general. If the quality of our system is
high enough, "play ball with us or go away" becomes a good approach.<br>
<blockquote cite="mid:5423A793-D42B-4780-B53E-7C3E9C3B0A57@ofb.biz"
type="cite">
<blockquote type="cite">Agreed. The catch is the delicate Unix-type
system hierarchy. Tell me, you clearly know more OS X than I: my vague
impression thus far (I have just a few hours on it tops) has been that
OS X has effectively two filesystem hierarchies, the Unix/BSD and the
user-oriented. Is this factual?
<br>
</blockquote>
<br>
Essentially, yes. /dev, /usr, etc. are there but hidden from the
user. The key ones for every day activities are Users (like home),
Applications, Library, Developer (optional) and System. They all do
essentially what you'd expect, save Library, which is a mix of plugins
and configuration files. Library also appears in each user's home
directory for user specific configuration files.
<br>
</blockquote>
OK. I don't think I will put much into this area for a while, although
a freedom-from-geekery GUI is definitely a good idea as a sub-project
or adjunct.<br>
<blockquote cite="mid:5423A793-D42B-4780-B53E-7C3E9C3B0A57@ofb.biz"
type="cite">
<blockquote type="cite"><br>
I do want to know what happens if one puts an ancient glibc in a chroot
with an ancient-glibc-based binary, on a new system. Does it work?
Does it crash the kernel (a joke, a joke)? Is there a way to get it to
work?
<br>
</blockquote>
<br>
I have no idea on that one. It sounds interesting. Perhaps you
could one up it and go for a very light virtualization? :-)
<br>
<br>
-Tim
<br>
</blockquote>
Good idea. I am using QEMU for 'core' candidate testing right now, and
I really don't need to go that far. Will do, assuming/after I find a
way to convince myself that a practical 'core' build process is within
reach.<br>
<br>
J.E.B.<br>
<br>
</body>
</html>