On Thu, 21 Aug 2003, Johnny Lam wrote:

: > How are those of us who would very much rather avoid having to deal with
: > a billion symlinks on our systems supposed to avoid this mess being
: > foisted upon us?
:
: We have an eye toward using hardlinks instead of softlinks to save on
: the inodes usage and to avoid the extra indirection, but that will be
: somewhere in the future.

What about the huge directory tree?  I hope this won't become the default on
a bunch of miscellany packages in the very near future, so we have time to
digest it and come up with alternative handling methods.  (Hardlinks still
doesn't cut it; in fact, that could make it even more annoying.)

I'll have to take a closer look at it.  I've used "depot" many times in the
past, and it had some major deficiencies wrt "etc" directories.  It left a
sour taste in my mouth.  In particular, absolute paths into the install tree
made it seriously difficult to put additional, optional config files into a
normal "etc" directory -- and made programs' dynamic updates of such files
even more painful.

That said, I can see some packages on my own systems that certainly would
benefit from pkgviews.  But in general, I'd rather not have a crapload of
extra package directories and symlink/hardlink farms sitting around for
*all* packages, when I maintain systems with literally hundreds of packages
installed from pkgsrc.

A suggestion to give us a fallback behavior:

* Once installed to the pkgviews directory and all necessary INSTALL script
  hooks are run, allow moving files into the shared directory wholesale
  rather than linking them.  This would simulate old-style package
  installation.

  This should be both a global and per-package switch, supported by pkg_add
  as well as bsd.pkg.mk, to indicate "this package is installed in-place".

* In case the binaries are using hardcoded pathnames to the pkgviews
  subdirectory, create a symlink where the pkgviews subdirectory would be in
  a normal pkgviews install, that simply points back to ${...BASE}.

* Add whatever logic is necessary to treat non-pkgviews files that reside
  directly in ${...BASE} as overriding any pkgviews file.  (I have not
  looked, but I'll assume this has already been done in order to provide
  coexistence between pkgviews and non-pkgviews installed packages.  Any
  existing logic will need a little extra kick to know that "in-place
  pkgviews packages" as defined here are basically the same as "legacy
  packages" in this respect.)

This alternative allows the whole thing to work with only *one* symlink
where the admin does not wish to use large link farms to achieve the current
pkgsrc install result.  If the above alternative is implemented, it could
even be set as the pkgsrc and pkg_add default behavor for a while, allowing
a more smooth transition path.

-- 
-- Todd Vierling <tv@pobox.com>