Preventing a fork
Maybe I just sort of used the 'proof by assertion' in that last message
(sorry! =) so I wanted to comment on a few specific points from Dan's
essay.
-FreeBSD development is based on a CVS tree, and virtually
every time an update is performed all of the binaries that
deal with processes need updating and rebuilding. This isn't
a big deal, as when -RELEASE comes out. everyone cvsup's to
the new sources and compiles their entire system.
In Debian, the development is based around CVS trees maintained by package
managers independently. If two or more utils need updating simultaneously
(assuming they're in different packages) then the packages will generally
require, e.g., a certain version of kernel package. See 'lsof'. It only
required a 2.0 or 2.2 kernel, but it could have required a specific kernel
version. The point I'm trying to make it is that it's trivial to match
versions with the packages if you were to package them with dpkg, and the
current FreeBSD method is not so incompatible with the Debian one.
-FreeBSD development maintains no compatiblity with previous
_system_ binaries This is mainly due to the fact that the
system binaries are updated when the user runs make world or
alternatively does a binary upgrade.
I think this is in line with what I was saying a moment ago -- if you have
a single package with kernel and dependent userland binaries, great. No
worries on versions. If not, then require the same versions so they are
upgraded at once. Again, (in theory! famous last words.. =) no worries.
-Should someone start another OS based off of FreeBSD, they
would have to constantly update every system binary to be
compatible with the new kernels for each release.
I don't see a problem with this. If you followed potato during its
unstable period I saw things like init get updated two or three times a
day on some days. If someone wanted the latest binaries that badly they
could just do the upgrade every day. It already happens with Debian
unstable.
-Users will be chained to the releases that their version of
the OS provides. It will not be feasible to let users try
-CURRENT.
You could deal with this the same way many Debian users do now, which is
to say ignoring the packaging system for some package, clamping down the
version (using '=' in dselect) and then installing your own in the same
place or with the Debian patches. If you want -CURRENT then you probably
have a machine that doesn't require quite as much stability as a -STABLE
system (like a developer's desktop).
If I installed the hypothetical DebianBSD system, there is nothing keeping
me from running cvsup, grabbing the sources, and doing a make world. This
would function the same way it does in FreeBSD now.
The following are features of the Debian userland that the
mainstream Debian user would like to see:
<snip, simplified package installer and abundance of packages>
See, I think that a point that several of us have brought up on here is
it's not all about the packaging system or packages. As many people have
said so far, the packaging systems aren't all that different. And Ports
has a lot of stuff in it. I'd just rather have the Debian versions of some
things like init.
Now, for Debian users who like the Debian userland.. We have
several options.
1. Take the FreeBSD kernel, isolate it, and build an OS around it.
Not acceptable, this would result in a fork.
2. Do #1, and base it on -RELEASEs. Take every -RELEASE and
debianize it. Lots of work. Lottts of work.
Maybe there's something I'm missing here but I don't see this. #1 taken at
face value would indeed result in some Issues =) and so is probably not a
good idea. I don't think people were suggesting that on face value (just
seperate the kernel and all the userland utils), but sort of a
modification that is closer to #2. The modification would be to allow
replacements for the BSD utils if you wanted the GNU/Debian version of it.
Also, what is the issue with #2? You just need to port a few packaging
utils from Debian at first, and you could fairly easily make a Debian
package out of the base system. I mean, assume you start just by forcing
the user to use the FreeBSD userland utils, and then Debian packages on
top of that.
Perhaps I am grossly underestimating the dependencies between the FreeBSD
kernel and the userland utils (like if 'cp' and 'tar' are kernel dependent
then there's a problem with this whole endevor... =). I don't see as much
of a problem here though.
I guess the best thing for me to do is shut up and start working on it to
see what I can produce (if no one else is doing it). If I run into all
these roadblocks then you can kick me an 'I told you so' =)
--
It's interesting to think that many quite distinguished people have
bodies similar to yours.
Reply to: