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

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Thu, Jul 24, 2003 at 09:41:52AM +0000, Floid wrote:
> In dragonfly.kernel, you wrote:
> >  From a user/sysadmin point of view I am all for a package system like 
> > the one debian.
> 
> [Obligatory fanboy drool for Matt and all others moving the project!]
> 
> Not to beat a dead horse here, but it seems like maybe you/we want:
> 
> -A system for maintaining/manipulating package builds from source;

Without touching the rest of the world. One might even support real
chroot builds by providing some tarball of the base system and a place
to fetch the dependencies.

> 
> -A system for installing said binaries, wherever they came from, in a
>  managed/manageable way.

Providing update facilities, checking for conflicts, etc.

> 
> Ports can be used this way (make package), but few take advantage of it,

FreeBSD ports can't really be used like this, since the package is
installed and _afterwards_ recorded is installed. If the plist is
wrong, you end up having dead files on your system.

> because the tools for dealing with packages aren't really there;
> pkg_add, pkg_delete, and now pkg_deinstall fighting with the latter.
> From what little I recall of pkgsrc, NetBSD might enforce the separation
> better by default, even if the manipulations it offers aren't really any 
> more "advanced."

That's what OpenBSD is doing. That's necessary to have good support
for subpackages as well. Just think of the XFree86 ports -- they are
a redundant mess. It would be much better, if there is just one port
generating half a dozen packages to be installed afterwards.

> 
> Basically, FreeBSD has a fairly involved source-manager ("Ports" and all
> the tools to manipulate it), with a "user interface" geared towards 
> monolithic trees.  I've no experience with apt, but it seems to be the
> converse - a very evolved package manager, with relatively few/lesser-
> known niceties for tracking source (and doing complicated, dependency-
> laden builds; you're expected to do complicated, dependency-laden
> binary updates?).

;-) Haven't ever tried to really rebuild Debian packages in 3 years of
using it. For source code, ports is more advanced. 

> 
> I'm most curious about the "Random Guy In Afghanistan" case.  Say you've
> got this random guy in Afghanistan -- he's smart, he's perceptive, 
> somehow he's gotten his hands on a laptop and "free software" of one form
> or another; he knows his needs (text editor, spreadsheet, whatever),
> maybe wants to develop some new software and sell/distribute it, etc.,
> but all he's got to the outside world is, say, a 56k link, possibly
> intermittent.  (Hey, wait, is this Afghanistan or Average Town, USA?)
> As it is, he either has to track fairly huge source trees, rely on
> binary packages (built with the features he wants?), or do most of his
> management by hand.  When he goes to distribute his own software, he has
> little choice but to reinforce the vicious cycle -- he can put it in
> Ports, or distribute it as a binary or source .RPM or .tgz... or maybe
> a Debian package with Far_Too_Many_Dependencies.  Even worse, his
> development tree probably doesn't live within any standard build/install-
> management system, so making it install cleanly is Extra Work, rather 
> than something that Just Happens.  (Contrast the Good Ol' Days, when you
> had fewer libraries to track, and software just lived under its directory
> or Amiga assign:.)
> 
> So, ideally, you want the source/build-management system modular and
> attractive enough that people will build to it as part of their development
> process, and that system modular and decentralization-tolerant enough that 
> Random Guy might be able to download Obscure_Freshmeat_Sources within that
> format already -- we could already be fulfilling that goal with Ports, but 
> the threat of namespace collission (and the annoyance of using Ports as non-
> root?) seems to put everyone off.

The problem is the dependency handling. We will need either a database
(I need a package provinding -lkrb.5) or some canonical way to name
packages. Both have there uses, but the later is simpler for distributed
usage.

> 
> .meanwhile, the package manager would just keep track of installed binaries
> however it sees fit, so it could care less if they're coming from 'official'
> trees, personal builds, or were downloaded prebuilt from package repositories.
> (In other words, let's not shoot managed source builds just to force people to
> fix the package-manager; the two systems should really be... orthogonal? ;))

Exactly. We might end with:
- pkg_add (already there, perhaps add some features)
- pkg_delete (same)
- pkg_update (some magic for library/server handling)
- pkg_version (already there, needs modular sources for packages)

- /usr/ports (similiar to OpenBSD's ports system, e.g. always building
     packages)

Joerg

> 
> -Thanks for the effort!
> -Joe "Floid" Kanowitz
> 
>