Re: Re: Debian BSD.. cool idea
I recall waay back on Jan 30 when Dan Papasian wrote:
> Since my workstation had motherboard failure, I've been using a box with
> UCB mail and vi ;) Please excuse the fact that I didn't quote messages
> with all of the fancy >'s as much as I could of, it is all being done by
> hand. (I'm going to install mutt after I finish this)
Yikes. I know how that goes.
> As a contributor to FreeBSD, I need specific things that you'd like
> us to fix. FreeBSD has a good stability record too..
> The message I'm getting (Which I'm damn near positive you don't want
> to send) is "Well FreeBSD is great but it isn't debian so lets put
> our name in front of it and use the names of our tools instead"
>
> You seem to imply that Debian would be bringing stability to FreeBSD.
> Isn't stability already there? Please elaborate.
Actually that part of my message wasn't talking about what I'd like to
improve about BSD, but what could be achieved with DebianBSD. I'm starting
from the perspective that I'd like to have Debian with a FreeBSD kernel.
So what I meant there is that (answering to the concept of setting up a
box on a pre-alpha version) we wouldn't have to worry nearly as much about
stability as, say, a pre-alpha of Debian Hurd (and of course, even that
carries over stability from Debian Linux) or a new architecture port of
FreeBSD or Debian.
> Same with the rest of the UNIX world. (FreeBSD Included)
> Things in /usr/local were installed by the user. Things in /usr were
> installed by the operating system.
But... for example: if you install _only_ the "base.tar.gz" file that is
like the FreeBSD "bin" distribution, you automatically get Perl and a
number of other things that definitely aren't directly supported by
Debian. They are supported in concert with the original authors (like Raul
said) but not by Debian themselves. Likewise, unless you do something
about it, Debian attempts to install Emacs for you by default (more like a
distribution package than an 'added' package). Even so, all that stuff
that got installed from the base tarball gets an entry in the dpkg
records and can be upgraded independently, even though the base system
depends on it.
I really think the discussion on this point is kind of moot though since
it's kind of like comparing apples and oranges. Linux isn't Unix and
probably never well be because of the mishmash of packages that make it up
(not just Debian).
The question is when moving to DebianBSD, should it continue the tradition
of installing packages from Debian into /usr, and the user installed
packages from source go into /usr/local, or should it go the BSD way and
install only the base packages into /usr? There are several answers to
that question:
- Installing just the base into /usr would pretty much make a radical
change to the way a Debian system is partitioned. It would be more like a
100 meg partition on average instead of 1+ gigs since most of Debian would
go into /usr/local with the normal Unix configuration.
- Debian packages are all configured to install into /etc and /usr for the
most part, so this might cause a lot of problems unless you could come up
with a reliable way to sed the descriptions or something.
- This _is_ going to be *Debian*BSD, and as Debian says, they're not just
a kernel... so the dominiant paradigm already in Debian makes more sense
to stick with in some ways. This is debatable of course since the Hurd
folks decided to install in /. And I guess it depends on whether you're
trying to add BSD into Debian or Debian into BSD. I'm rooting for the
former personally.
- If you break packages up and keep a strict seperation, then things can't
put a startup script in /etc/init.d/.
Those are the against's. On the other hand, here are some positives:
- Seperating the system into three parts could be an interesting thing --
/usr for Debian base stuff, /opt (/usr/opt?) for installed packages, and
/usr/local for stuff installed by hand. At least that way you can make
/usr and /usr/opt one partition.
- If it's going to be inheriting that much of FreeBSD, it might be better
to bite the bullet and use a standard Unix layout, since most of the
"base" system would BE FreeBSD.
There are more I'm sure but those are some that come to the top of my
head.. in reality it's going to depend entirely on who has the proper
amount of free time to implement the first version first =D
> Except MySQL is a 3rd party package, so it shouldn't touch much below
> /usr/local. It should go into /usr/local/var (or /var, depending)
> and /usr/local/etc.
But it's not a 3rd party package. I didn't install it myself, it came from
the vendor. It just happens that they didn't write it. I'm saying that
this distinction doesn't mean as much in Linux as it does in BSD. If you
take that approach, then it's arguable that even things like dpkg are 3rd
party since Software in the Public Interest didn't write them (pushing it,
I admit... but still =)
Ok, we're getting heavily into the IMHO part here, so all these replies,
please take them with that attached.
> Yes, dpkg on paper handles conflicts in a much nicer manner. There will
> be conflict handling with 5-CURRENT. The user is expected to read the
> README with each port to see if it conflicts, and remove older versions
> before installing newer ones. Perhaps this is too much to expect, yes..
It's not a matter of "too much to expect" here. I think this is something
that the system ought to handle by itself, or at least warn you about. I
don't think it's reasonable when the system is setup to be installed from
a nice menu driven installer to make people go out and read stuff from the
ports tree. It's not a matter of laziness as much as it's breaking the
paradigm. Unless of course you can do it from the menu driven installer,
and then it might be a better tradeoff. Example: dselect shows you a short
readme-style blurb in the bottom half of the screen by default. This has
been extremely useful to me personally. Redhat allows you to hit F1 in the
installer to get a readme blurb about the package. Something like that
might be useful in sysinstall (ok, there's your specific suggestion ;-)
> But it is still easier to just fix FreeBSD then make another OS out of
> the thing :) I used Debian exclusively from when hamm was just getting
> onto CDs until a month or so slink went glibc2.1.
> I've been using FreeBSD for 8 months now, and contributing for 1 month.
> I've had _less_ hassle with ports/pkg_add then I ever had with dpkg.
> While the feature is lacking on paper, Real Life Usage(TM) shows ports/pkg_add
> to be superior. (Of course, YMMV)
> I don't see how Debian handles dependencies better. DEPENDS with
> ports/packages works fine.
Yeah. I will definitely agree with you on the paper vs reality thing.
Using dselect with, e.g., an unstable Debian distribution (generally the
only thing worth having on a user machine, IMHO, since it's up to date
enough) is a big nightmare. Selecting some random package may trigger a
dependency that installs 10 more packages, and then those trigger
conflicts that try to uninstall your base system... it is a big mess. For
that I wish for some more simplicity, but in my mind it's still better to
cause problems up front than to get mysterious behavior later on when
something overwrites something else unknowingly.
Buuuuut... on the making a new OS vs fixing the original, I think the
point is that people want to attempt a Debian / FreeBSD hybrid anyway, and
this doesn't adversely affect your ability to use FreeBSD. If you like it
better, then by all means, keep using it! =) I like Debian better, but I'd
like a BSD kernel. If there's a happy medium where we don't need to
recompile all the packages in Debian for the BSD kernel immidiately, but
it is possible to install that way, I'm all for at least playing with it.
> Well I'm not involved with the documentation ;)
> Yes, I do fiddle with src/ and have patches commited for me, but I'm
> not a commiter and I'm definetly not -core :)
> So I don't represent FreeBSD in any offical way.
Oh well... I still think that hier man page rocks. =)
Scary enough, I've already started tinkering with the FreeBSD kernel... I
have a patch (probably undesirable for most people.. but good for my work)
that makes unionfs 'uncover' a shadowed file when you rm the upper layer's
copy instead of using whiteout. I've also got a patch to mount_portal that
makes it submit the extra path contents to the tcp port you connect to,
which is useful for creating files on the fly with context. I have found a
few bugs in unionfs already (or rather, stacking layers in general) that
it would be cool to fix but I'm still not quite there =|
> More of the above: Things good with FreeBSD :) I get the feeling that
> the next entries will be things that I have to defend/fix :)
Well.. again, I am just trying to brainstorm out some thoughts from the
point of view of a Linux user and a Debian user as to why I'd like to see
a DebianBSD. FreeBSD is a nice system on its own, and I'm not trying to
say that it needs to take a hint from Debian. I would just like to mash
together BSD and Debian for personal usage =)
> The only issue that I know about with FreeBSD packages are conflicts
> and lack of version handling (i.e. bash-1.1 and bash-2.0 look like two
> entirely different packages to pkg_add)
> This will be addressed in 5-CURRENT. If you have some immediate patches,
> send them over :)
This is also done in dpkg to a great degree these days. It's not uncommon
to see "xlib" for libc5 and then "xlibg" or "xlib6" for libc6. I have
heard a lot of complaints about it from some of the developers of course,
but dpkg can't handle these version issues as well as it needs to for
co-existing packages of different major versions.
I guess another of the big advantages to dpkg over pkg_add (or even rpm)
is that you have apt or dselect to go out and figure out what you need to
upgrade to come up to date on your installed software. This can produce
problems (see depends/conflicts discussion above) but it is also a very
nice system administration tool. It means I don't have to keep on top of
what's changing, and I feel like that's the kind of thing the computer
ought to do for me.
There is probably similar functionality in sysinstall that I just haven't
found yet. So, FIMWA (foot in mouth warning applies) ~=)
> As FreeBSD rebuilds its packages quite often (we have several fast computers
> to do that for us :) it isn't much of a hassle to change formats.
> As a quick check with bento (package builder) shows, all of the packages
> were rebuilt Jan 30, 4:00AM. That is what, 10 hours ago? :)
Is 'bento' a reference to Japanese box lunches? =) That would be lovely
for a package builder..
> Where I'm getting with this is that flaws in the package format
> are easily addressed. Just fiddle with bsd.port.mk to have it not use
> pkg_create and instead use dpkg_create or whatever, and you can convert
> all of the 3000 ports/packages from FreeBSD's format to Debian's.
> Of course, that would be more of a hassle to do then fixing our format, but
> you never know :)
>
> Centralized package building allows for painless modifications to the package
> format (Although people expect that the package format will remain somewhat
> constant, so this is something that can only really be done with a .0 release,
> and it didn't make it for 4-CURRENT)
It is definitely a nice thing there. I think at this point Debian has so
many packages that they'd have trouble doing a central compilation pass...
for what, 6 architectures now? ack! Plus it's kind of part of the design
that the package maintainers take care of all that to make sure it happens
properly. I guess there are pros and cons to each way of doing it.
> <<- A nice Debian package for the BSD base system. I guess this would end up
> including a kernel and the equivalent of the "bin" distribution, at least
> at first. Maybe it could be broken up for finer tuned upgrading later, but
> I know that's generally against recommendations =) >>
>
> The problem with the current method of managing the base system with
> cvsup/make world is? (There are binary upgrades available too, via
> sysinstall, but they are less popular. I've heard only good things
Nothing wrong with it. But like I said, I'm not trying to criticize
FreeBSD, I'm trying to figure out how you could fit BSD into a Debian
system. The most obvious way to do that is to create a deb file that has
all of the base FreeBSD software with it.
> Now, off to install mutt via pkg_add -r mutt :)
Enjoy ;-)
--
We'll cross that bridge when we come back to it later.
Reply to: