Subject: Re: Packaged for NetBSD (Was: Why are there two 4.4BSD dev. groups)
To: None <current-users@NetBSD.ORG>
From: Bakul Shah <bakul@netcom.com>
List: current-users
Date: 01/08/1995 15:59:37
I have a number of comments on this subject.
- A URL that lists which packages are known to work and
where to get them will be very helpful. If they are in
the pkg format so much the better. If a binary
distribution is available that'd be great but the key
thing is to put this info. together in one place. Ptr to
this URL can be posted via FAQ or something.
What will be even niftier is a mechanism like this that
can be used for any package for any OS on any machine
architecture. This can be specified by a tuple: name, os,
arch, author(s), version, description, source location,
binary location, comments, certification, see-also, etc.
Sort of a global, distributed database for packages but I
think I am dreaming:-)
- Notice that an install is not intrinsically tied to a
specific package. In general, we have a set of packages
that must be installed together and an open set of
packages that we may wish to install. Some packages
depend on other packages. Then there are things that need
to be done to `prepare' for an install (e.g. formatting
and partitioning a disk) and things that need to be done
to `finish' an install. We can similarly define what it
means to `remove' a package as well as upgrade a package.
If we can describe such lower level details in a machine
independent fashion, it should be possible to write a
number of different installer programs that operate in
different environments but feed of off the same description.
The benefit of abstracting out the installation process
in this way is that we can install NetBSD or some package
on top of NetBSD or pretty much anything else using a
standard style of interaction. If we have access to X
windows, we can use a fancier installer with all sorts
of bells and whistles but an initial install of an OS can
be quite parsimonious.
Of course, this is an idealized model and we won't be able
to abstract out everything. Even so, this will be a big
step up from install shell scripts. It should also allow
you to cleanly uninstall a complete or partial install,
query which things have been installed etc.
The user interface should allow you to *mark* which things
you want to install before installing them (as well as
mark which things you want to remove before removing
them). If you are connected to the 'net, you should be
able to install pretty much anything (assuming my dream
above becomes reality!).
- While NetBSD suffers from a lack of such tools more so
than Linux (and even FreeBSD), I sincerely hope we can
come up with a solution that is not specific to NetBSD.
Comments?
Bakul