Re: Re: Debian BSD.. cool idea
On Sun, Jan 30, 2000 at 04:38:42PM -0600, Dan Potter 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.
Well, I've got mutt now. And it was under warranty. With onsite tech
support :) (not as if I have no qualms with doing it myself, but hey)
> > 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.
Considering the kernel is so interwoven with the OS, it is more feasible
to take the route of staring with FreeBSD and then worrying about the
high-level administration tools that make debian feel like 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.
So you'd like to be able to impartially upgrade the base OS?
It is possible with anoncvs and freebsd, but not recommended for end-users.
This upgrading thing is seriously overrated. You should have to upgrade
things only on rare occasions (bugfix, new feature..)
> 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).
And considering FreeBSD is a living, breathing entity, it is this issue
that will make it hard to create Debian/FreeBSD without getting some people
pissed off.
> 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:
Considering you can override the PREFIX and have it install ports to /usr,
this issue is moot. Let the user decide.
<snip>
> > 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 ;-)
Request noted. When setup (2nd-gen sysinstall) sources are born, I'll
make it a point to add that feature.
> > 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.
Read my essay at http://bugg.strangled.net/debbsd.txt
I explain why Debian / FreeBSD could be bad to everyone, including
existing FreeBSD users.
> > 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 =|
Use send-pr and submit those patches! :)
If they aren't wanted, they won't be commited.
> > 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 =)
If it is done carefully, it would be a good thing, yes. (see my essay)
> > 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.
Luckily for *BSD users, they don't have to worry about competing libcs
like that :) compat2x, compat3x packages can be installed and never
have to give it another thought again.
> 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.
I dont really have dependency problems, no matter what I install.
(And I had a ton with Debian! :) )
And, apparently you aren't aware that pkg_add does that too.
pkg_add -r napster will do the exact same thing as apt-get install napster.
Go try. I'm telling you the truth! :)
And we all know ports handles dependencies.
> There is probably similar functionality in sysinstall that I just haven't
> found yet. So, FIMWA (foot in mouth warning applies) ~=)
If you do the post-install configure, add packages, it'll handle it too.
But I don't go into sysinstall at all anymore, with ports and pkg_add -r
by my side :)
> > 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..
Probably.
bento (for -stable, and contains information about -current builds as well)
is owned by the ports team, which is headed by Japanese Satoshi Asami :)
The box that builds -current packages is called builder, which isn't
nearly as creative.
> 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.
Well, the cross architecture builds just requires more computers :)
But, until our non-x86 ports start catching up, we don't have to worry
about that much. You want MIPS/PPC/alpha/sparc packages? Build them yourself :)
It is still up to the maintainers of the ports to make sure it happens
properly. They make a Makefile and PLIST and whatnot for the port, test
it out, and have it commited. They just write how to download/compile/install
the program in the ports syntax and get that commited: then people can
install via ports or wait for the package to come around when the applicable
box (bento or builder) compiles it and makes a package.
That would be the advantage to having a company behind the project, money
for fast machines to build 3000 packages/day :)
(note there are 8 other boxes that help bento/builder, if I understand
correctly. I'm not that involved with ports :) )
> 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.
The thing is, it seems like we are being criticized.
The message is "Oh, your OS is great, but we are redesigning it anyway"
:)
-Dan Papasian
<bugg@bugg.strangled.net>
Reply to: