[ On Thursday, August 21, 2003 at 19:21:23 (-0400), Todd Vierling wrote: ]
> Subject: Re: Package Views Integration (finally!)
>
> In fact, I've already addressed this particular issue (configuration files)
> at length and offered an alternative that you may not have taken the time to
> read yet.  I don't feel like rehashing the whole damned thing all over again
> just to get back on topic.

Yes, I did read your post -- but as far as I could tell your proposal
failed the first important test:  K.I.S.S.

> What I asked is how there's any difference ig pkg_add allows depot-style
> installations, when that behavior doesn't have to be used.  If you'd bother
> to read my fallback alternative suggestion, it gives a very nice and neat
> way to deal with the whole mess while still gaining the benefits inherent in
> building to a depot-like install prefix.

pkg_add is obviously not what I'm worried about -- it's getting to that
point which is the problem.

Your idea to put a symlink back into the pkgviews subdirectory to
compensate for hard-coded pathnames creates exactly the same problem as
pkgviews creates in the first place but now in reverse, and now in an
even more subtly twisted and confusing way that's even easier for a
naive administrator to break unknowingly.  Whether it is one symlink or
many is irrelevant.  My goal is to have zero symlinks and thus no
possibility for confusion or accidental breakage.

What we really need is one simple flag to totally disable the use of
pkgviews during all builds -- i.e. to leave things as they are if that
flag is turned on by the pkgsrc user.  This shouldn't be hard to do, but
doing it undoutably requires at least a minimal buy-in by Johnny and
whomever else is going to actually integrate pkgviews support.

BTW, I've never heard or seen any real wide-spread benefits for to using
a depot-like system for the majority of production users.  As you've
said yourself pkgviews is a huge amount of additional complexity for
very little gain.  The whole idea ignores the K.I.S.S. principle from
beginning to end and adds complexity for what seems to be complexity's
sake.

In my experience very few production users really need the ability to
have many versions of _all_ packages at all times, and in most of the
cases I'm aware of where production users need simultaneous access to
multiple versions of specific tools those tools already have native
support for allowing multiple simultaneous installs of those different
versions.

Furthermore adapting more packages to natively deal with having multiple
versions of themselves installed is a far more laudable goal in the
scope of larger community outside NetBSD, especially when it makes sense
to have multiple versions of a that package simultaneously accessible by
end users.

The fact that pkgviews also "solves" the issue of upgrading packages
upon which many other packages depend upon is an accident and a bad hack
-- it is not a real solution to the problem and it simply causes a lot
of additional bloat that's not really neccessary to implement any more
elegant solution to the underlying problem.  It doesn't take much
imagination to extrapolate from the first use of pkgviews to upgrade
some interdependent package into a future where any system lazily
tracking pkgsrc (i.e. only upgrading a few things as necessary) will be
so clogged up with multiple versions of many packages that their only
solution will be the same slash and burn ("make replace") currently
faced by anyone doing the same without pkgviews.  Ultimately the only
big problem with the slash and burn technique (other than the time it
takes) is that it's much harder to individually test each upgraded
package along the way.  Using static libraries everywhere possible, and
thus avoiding the worst of the inter-dependencies currently plaguing
pkgsrc, is almost infinitely simpler and far safer while at the same
time allowing full and independent testing of each upgraded package in a
full environment matching the production environment.  With static
libraries one can even backtrack a library dependency for some new
packages without having to worry about disrupting any other package
which also uses that library (i.e. for the specific case of object
libraries the use of static-only libraries implicitly allows for any
number of simultaneously "installed" versions because there is of course
almost never any to conflict or anything to depend upon -- the right
version of the library code is always tightly coupled right into the
applications which use it and by comparison any and all forms of shared
libraries are a management nightmare).

Finally as far as I can see the ability to frequently upgrade highly
interdependent packages still only an issue for those on the bleeding
edge -- it is just not a problem faced by most production users.  It's
not even a problem for bleeding edge developers if they've got enough
resources to properly build and test new versions in isolation.

-- 
						Greg A. Woods

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