DragonFly kernel List (threaded) for 2003-07
Re: Remove BIND, Sendmail, Perl and etc from base?
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
> .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
> -Thanks for the effort!
> -Joe "Floid" Kanowitz