DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Remove BIND, Sendmail, Perl and etc from base?

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Thu, 24 Jul 2003 09:35:48 +0200

On Wed, Jul 23, 2003 at 10:01:56AM -0500, Peter da Silva wrote:
> Joerg Sonnenberger wrote:
> >As a matter of fact, OpenBSD ports can do most of portage without the
> >need of portage and they are normal Makefiles.
> I would definitely prefer that this be based on the BSD ports system, 
> with ports and packages in easily understood tarballs.

At least for the packages there are good reasons for not using tarballs.
Tarballs are not really good for streaming. E.g. you want to install
a package from ftp, you are an innocent first time user of the package
and it fills some of your partitions and installation fails. With a
real streaming format, pkg_add could verify that before installing the
package and the same is true for conflict checks (which might become
obsolete with layered/virtual filesystems). An archive format with
leading filelist is the best for such a job.

> I also think it needs to be looked at as it progresses. It doesn't
> make sense to have every file in /bin be a separate package...
> there are definite clusters of components that make sense to
> collect together, and I don't really like the idea of stripping
> things all the way down tothe Linux level either. But certainly

I don't like the idea of bin_sh either. But the having a real base_bin,
base_sbin ... package is much better.

> there are large chunks of the FreeBSD system that are in the
> "core" that, even if they remain inthe base install, should be
> abstracted into packages.
> Perl
> Sendmail
> gcc
> nvi
> .

Kerberos, lpd, ... ?

> Basically, at the very least anything that's a third-party program
> should be kept that way. Maintaining a separate "sendmail" tree just
> doesn't make sense.
> Going from there to things like the stock bin tools, let's just
> see how it works up to there. It may make sense to keep a real core,
> or it may turn out to be so easy to use the packages that there's
> no point to NOT stripping everything down.

Well to add the idea of dynamic root, I suggest something like:
- rescue => contains /stand with static versions of /bin and /sbin
- base_lib => contains /lib, /lib/ld.so, /usr/lib
- base_sbin => contains /sbin and /usr/sbin
- base_bin
- base_devel => /usr/include and /usr/lib/*.a
- third party packages


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]