Subject: Re: xsrc4 & perl (Was: Re: UUCP removal from OpenBSD)
To: =?UNKNOWN-8BIT?Q?Jarom=EDr_Dolecek?= <jdolecek@netbsd.org>
From: Rick Kelly <rmk@toad.rmkhome.com>
List: current-users
Date: 10/08/2001 20:01:15
Jaromír Dolecek said:

>> In fact, I have a scheme on how to get rid of the current scheme of
>> sets files in src/dist and do things towards having a packagized
>> install in a far more natural manner, all as a side effect of some
>> work Wasabi is doing towards making it possible to do full system
>> snapshots without being root.

>Cool.

I'm still not all that certain about a packagized NetBSD.

Right now there is one installation tool that is always guaranteed
to work: tar zxvpf

When you look at Sun 3/50 and 3/110 that is probably the best install 
tool to use. Other machines like hp300, pmax, and Sun2 may be in the
same boat. The Sun 3/50 is becoming close to useless with NetBSD due to
the memory hole. Even the INSTALL kernel leaks into video memory at boot.

The machine that I'm typing this on is a P200 that initially started out
running NetBSD 1.3 and is now running 1.4.3. I've had the pkgtools on here
since 1.3, with obvious upgrades to the tools for new releases of pkgsrc.

The pkg database is now greater than 4.5 megs, and doesn't give an accurate
reflection of what is installed. There are things that got removed by
"make update" that were removed and didn't get updated, however, they
are still listed as installed according to pkg_info. Just recently,
in August, I pulled down the latest pkgsrc and installed a package. I had
to do a "make update" and it removed all things related to TeX, and didn't
replace them. However, the pkg_info database still shows the originals as
being installed. I refuse to trust the rev level of the OS to a set of tools
that are obviously in transition.

And my method of upgrading the OS is usually "cvs update" and "make build".

The current binary tarballs that are supplied for NetBSD are suitably divided
up into appropriate capabilities. I just don't see that we need further
granularity.

-- 
Rick Kelly  rmk@rmkhome.com  www.rmkhome.com