Re: Re: Debian BSD.. cool idea
I recall waay back on Jan 30 when Dan Papasian wrote:
> 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.
See, I'm once again of two sides to that argument. Part of the reason I
personally like Debian is that everything you don't install from sources
is a package with tracked file lists, and can be replaced or upgraded at
will. Rebuilding the FreeBSD basic distibutions as deb's would seem like a
better paradigm for a DebianBSD system.
> 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..)
True enough, but you're again speaking from the point of view of the OS
itself (i.e., the FreeBSD-style OS package with kernel+utils). The base
system very rarely gets upgraded in Debian's stable branch, and even in
unstable it doesn't happen as much as it could given the infrastructure.
Unstable is for developers though so it's not really germane to the
discussion.
The thing is that the "system" is integrated with the extras in Debian,
and so the same upgrade process is used with both. It's nice to be able to
say "go see what's changed" and then decide what I want to replace for
security fixes, etc.
If you want to force a simultaneous upgrade of all base components, you
can use version dependencies (==) in deb packages.
> 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.
Good lord yes.. Debian people too. Look at the devel list archives and
search for BSD...
That has never stopped me before though if I get interested enough in
something. If someone creates a bastard stepchild of Debian and BSD and I
like it, then I will use it, so poo on everyone else =). They can ignore
it and think it's evil, and I'll get the functionality I want. That's what
this whole open source thing is about.
> Considering you can override the PREFIX and have it install ports to /usr,
> this issue is moot. Let the user decide.
But Debian packages aren't always so flexible. They usually don't just
install into /usr, they drop files in /etc and /var to remain integrated
with the rest of the OS (see my MySQL example). I guess they could go into
/usr/etc, /usr/var, and /usr/bin, but that's not Debian either so what's
the point =)
> Request noted. When setup (2nd-gen sysinstall) sources are born, I'll
> make it a point to add that feature.
Thanks! I think it will be a nice thing to have.
> Read my essay at http://bugg.strangled.net/debbsd.txt
>
> I explain why Debian / FreeBSD could be bad to everyone, including
> existing FreeBSD users.
I will take a look!
> Use send-pr and submit those patches! :)
>
> If they aren't wanted, they won't be commited.
Thing is, the man page specifically mentions the desire to have whiteout
functionality in unionfs. If I can make it work on a file system option,
then I'll definitely submit it.
More importantly, I'd like to find a way to get device files to work over
a layered FS. In both nullfs and unionfs, attempting to even list a
directory containing device nodes causes the system to reboot.
The portal thing is something else -- I'd love to see someone complete the
part of mount_portal that interfaces to things besides tcp and the root
fs, since that's basically a simplistic userfs. If I get that worked out I
might submit it.
> If it is done carefully, it would be a good thing, yes. (see my essay)
Agreed there, I'll look at the essay in a bit.
> 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.
Yes. Well, that is the idea behind the Debian packages too -- you can
install the libc5 libs seperate from the glibc2 (which is libc6, aggghh!
=), and the progs will be fine with their library dependencies. That is
all good. The problems arise from when you need supporting libs that link
to the older system libs. Then the easiest way in Debian is to make a new
package name instead of version and they're kept totally seperate.
> 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.
That is lovely. I think I saw that in the man page but I didn't try it for
the case I needed it so far.
> 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 :)
Heh =). There are lots of people who don't use dselect any more either,
but I like to see a preview of what's going to happen and tinker with it
before it's committed.
> bento (for -stable, and contains information about -current builds as well)
> is owned by the ports team, which is headed by Japanese Satoshi Asami :)
That would do 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 :)
That is pretty much the Debian approach to the lesser supported archs
too at this point =)
> 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.
See, I guess my ignorance of Debian will show here too. I was under the
impression that the author makes the deb and uploads it with the source
files, and then the archive dumps it in. But I also have heard of official
build machines for other architectures; I guess those are for the authors
to use to build deb's. Maybe they have a central compilation, I don't know
though.
> > 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"
>
> :)
Hmm... I guess I have a tendency to do that some times... so my apologies.
But that is basically what I am saying. Obviously there is some interest
in seeing FreeBSD as an OS redesigned to fit Debian or there wouldn't be a
mailing list. Or maybe it's a mailing list of people interested in seeing
Debian ported to FreeBSD as an OS, and I'm misguided =). I don't think
that there is really a conflict of interest in maintaining FreeBSD with
its ports system, Debian with its deb system, and having a middle ground
where you have FreeBSD with the deb system.
Anyhow, I'll take a look at the essay and maybe I'll change my mind about
all this... in which case I'll probably just forget about it. =)
Thanks for the discussion so far though. It's brought up some issues I
hadn't though of.
--
It is the quality rather than the quantity that matters.
- Lucius Annaeus Seneca (4 B.C. - A.D. 65)
Reply to: