[ On Wednesday, March 19, 2003 at 14:22:00 (-0800), Aaron J. Grier wrote: ]
> Subject: Re: why separate system and pkg hierarchies? (was: /usr/pkg/etc/rc.d/*)
>
> I've had troubles in the past with stuff from pkgsrc clobbering base
> system files (texinfo and ncurses come immediately to mind) which make
> it tougher to update the base system, as well as build issues (glimpse
> and spice) which are pain in the asses.

Well, those packages are effectively broken then, especially if the
clashing files are ones in a "bin" (i.e. $PATH) directory.

Texinfo is a bit of a special case though because there's nothing
really unique to the base system implemenation and it's good to be able
to replace the base system version by simply installing the package
version with LOCALBASE=/usr (just as we do with pkg_install, and as I do
with bind8 and a few other things too).

> > How does installing a package in a system hierarchy make it more
> > difficult to upgrade your system?
> 
> I install base system
> I install ncurses from pkgsrc with LOCALBASE=/usr
> I upgrade base system via existing blessed method (drop a tarball from
>   the root directory).
> 
> how would your LOCALBASE=/usr system handle this situation?

Well, first of all I don't ever install ncurses -- the system curses
libraries and databases should have all the equivalent functionality.
I've fixed the few odd brain-damaged packages I do use that think they
need ncurses.

The same rule applies to readline, FYI, because it conflicts with the
very different (but partially compatible) base system implementation.

In theory the ncurses package need not have any files that conflict with
system files even when ncurses is installed in the base system
hierarchy.  That was true many years ago when I used ncurses on older
SunOS and ISC systems and so should still be true today (perhaps with
some minor tweaks).

On the other hand if your goal is to replace the system curses with the
add-on ncurses package then you really are in a pickle unless you've
static-linked your whole base OS (in which case you're not really
replacing the base curses, but simply making it appear to have been
replaced from the point of view of builds of other add-on packages).

The readline package is a bit more problematic because of the way other
packages generally discover it and configure themselves to use it.  It
may be easier to address now with buildlink2 though there are still some
problems with getting full buildlink2 functionality on a system with
LOCALBASE=/usr.

Ultimately with readline the same solution is needed:  implement the
functionality missing in the base system variant and be done with it.
Indeed with readline there'll be much less hassle with other add-on
packages because few, if any, are already expecting a situation where
there might be multiple readline implementations on a system.

> do you have a pkg-ized base system too?

Not yet, but I really should.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>