Re: Modified load-path proposal

[Greg Troxel]

before deciding about tags and descriptions, I think we need to be
clearer on the semantics of these directories and why they'd be used.
Let me take a stab at it, and I'm sure I'll leave out other's use
cases.

$(guileprefix)/share/guile

    top-level place within guile's prefix.  currently has slib on
    NetBSD pkgsrc (symlink to /usr/pkg/share/slib) and slibcat file.

$(guileprefix)/share/guile/site

    unclear why this is used rather than above, unless it's for
    sysadmin-managed stuff within guile's prefix rather than
    pkg-managed.  On NetBSD pkgsrc database (ttn's guile-pg) lives
    here.

$(guileprefix)/share/guile/1.6

    Currently, stuff that is actually part of guile; I haven't seen
    other packages install stuff here.

$(otherprefix)/share/guile

   probably where to put generic non-pkg-managed stuff, although that
   raises the issue of why a different prefix was used, but pkg
   systems may want to do this

$(otherprefix)/share/guile/site

   non-pkg-managed stuff, done by group sysadmin.  But, it seems
   likely that the use of otherprefix serves the purpose of site.

A related point is whether it is ok to install two versions of guile
in the same prefix.  It seems that at least some things conflict, and
this really doesn't work.  NetBSD pkgsrc has support for 1.4 and 1.6
at the moment, with 1.6 default and 1.4 as guile14.  guile14 is built
with /usr/pkg/guile/1.4, so it's in a totally different place, and
things that use it (not too many now) link there.

So, if we can't install two guiles in the same prefix (which is fine;
prefixes are fairly cheap), then it makes sense to declare that the
1.6 subdir is for things that are part of guile (meaning built from
the distribution).  Packages built against 1.6 would record a
dependency, and you'd expect to have to rebuild them or get a version
built against 1.8 later, just like packages built against anything
else with a possibly changing ABI.

Also, it could well be that the whole 'site' notion is outdated.  This
made sense back in the days of 4.3BSD, but with packaging systems
doesn't so much, especially since the right thing to do is to have a
separate prefix from the packaging system.

So, my proposal is:

  $(guileprefix)/share/guile

     This is where pkg-managed modules should go.

     Those that think it is reasonable for programs configured with
     other prefixes should put them here, unless their package system
     says they should somehow keep non-pkg-managed stuff separate.

  $(guileprefix)/share/guile/site

      Historic/deprecated.  Created by guile, but nothing put in it.

      If someone is using non-pkg-managed stuff across multiple
      machines, perhaps they should put it here.

      If someone is using non-pkg-managed programs, but using the 'put
      in guile's prefix' approach, perhaps all that stuff can go here
      so the non-managed stuff (viewed as turds by things like
      pkg_admin check to find unregistered files) will all be in one
      place.  Thus this should perhaps be the default for macros
      called to ask for guile's prefix.

  $(guileprefix)/share/guile/1.6

      As it is now: files that are part of guile.  Others are strongly
      discouraged from putting anything there.


  $(guileprefix)/share/guile/local

      This would be like the old local vs. site.  There seems to be
      little need.  The 'add arbitrary dirs' scheme would support
      this, but guile should just ignore this and not mention it or
      put it in my default.

  $(otherprefix)/share/guile

      This is where I'd put modules installed aftetr configuring for
      another prefix.  Whether this is site or local can be encoded in
      otherprefix.  Adding a 1.6/1.8 dir won't fully solve the API/ABI
      compat issue, and doing it halfway will lead to trouble


Then, the GUILE_SCHEME_DIR macro should take a token which is either

  guile-prefix
  own-prefix

and return one of (depending on how we feel about protecting pkg
systems from people who want to install non-managed stuff in them)

  $(guileprefix)/share/guile
  $(guileprefix)/share/guile/site

or

  $(otherprefix)/share/guile


Optionally, one should be able to specify either a replacement for
share/guile or further components, perhaps when using either
guile-prefix or own-prefix, and this should then generate or enable
code to hook the dir into guile's load-path at make install time.

So, I think my cross-product idea was not so good - the current 3
places are a bit messy/historic rather than really the right thing to
do.

-- 
        Greg Troxel <address@hidden>