Re: Re: Debian BSD.. cool idea
I recall waay back on Jan 30 when Steve Shorter wrote:
> There are many other reasons to prefer the GNU tools both
> technical and political. But that is completely NOT the point. The point
> is that *I* want the GNU tools because *I* think that they are better.
> So why can't I have them and the Debian package system and the FreeBSD
> kernel? Isn't that what freedoms all about? The freedom to choose.
I hope I didn't come across the wrong way in my last message, but that is
basically my point as well. It isn't a matter of which one is better, but
which one people are more familiar with and/or like better for themselves.
I prefer the Debian method for many things, like init, fs organization,
etc. That doesn't mean everyone has to like it. That's why I'd like a
middle ground to have it both ways.
> I want M S 's sys5 init and the Debian administrative system
> as it is now and will improve and evolve into. There is no point
> debating whether they are "better than the BSD way" in this forum. That is
> completely NOT the point. The point is that there are many technical
> people who want them and DebianBSD would be a welcome and valid contribution
> to that community.
>
> So M S's sys5 init + GNU tools + debian package system + debian
> administrative "System" + FreeBSD kernel.
>
> Why not?
So I read the essay Dan suggested, and it makes some good points. I guess
the main fear here is the idea of a forked FreeBSD kernel. IMHO, this
simply won't happen, for the same reasons it doesn't happen with Linux --
it's counterproductive. It is of paramount importance to avoid a fork in
both the FreeBSD kernel and the Debian utils, because this would draw
developers away from either project, and become an administrative
nightmare. But it really shouldn't be that difficult, should it?
For example, I needed the Debian python-mysql package from slink, so I
downloaded it, extracted it, applied patches, and compiled it. Minus some
stuff I didn't have installed from ports, it worked fine. So I'll suggest
this again. Why not have:
- A FreeBSD kernel + userland utils package. This would include the base
system utils and a matching kernel. If a user wanted to do a major version
upgrade, they'd have to build a boot disk and do it that way I guess. I
know, I tried it the other way. I reinstalled. ^_^; Alternatively, a
statically linked upgrade util for system packages ought to work -- it
would kill stuff that's running, replace the system binaries, and then
reboot with the new kernel. Just a thought anyway.
- A FreeBSD package or set of packages, matching in version number to the
kernel+sysutils package, which implements things like ls, cp, etc.
- A dpkg install method that looks for the package in a cache somewhere
(i.e., someone else has already compiled it for you), or alternatively it
downloads the source and does a ports-style compile to produce a deb file.
This deb file is then fed into apt/dpkg/etc and installed normally. You
get ports-style functionality but with version control through dpkg.
It's a bit of a kludge, I'll admit, but it meets my goals pretty much... I
want a FreeBSD kernel and the utils neccessary to make it work (sysutils
that are integrated in CVS), and a choice on the other ones between BSD
and GNU. I don't see how this would promote a code fork since it's a
maintenance issue rather than a porting issue. This is obviously a naive
view of the situation above (which is more complex) but this is what I had
in mind.
--
Every day it's the same thing -- variety. I want something different.
Reply to: