On Sun, Feb 15, 2004 at 04:47:17PM -0600, Min Sik Kim wrote:
> (...quotes stripped...)
> I like having one meta package and seperate packages for lisp packages
> as emacs-packages does.  We can still provide a SAWFISH_THEMES-like
> variable to customize the meta-package.

Actually I don't think this is enough. I've stumbled over this when I
was thinking about creating pkgsrc pkgs of my tcl and ruby stuff, the
situtation as-is is just catastrophal for extensible software in
pkgsrc. Here is a off-the-top-of-my-head requirement list for packages
which are add-ons to some sw pkg:

* needs to be installable globally and locally, per user
* sw pkgs need to be tweaked to search for a addon first globally,
  then locally, pkgsrc-wide.
* sw pkgs containing addon pkgs should add another level in pkgsrc,
  to demonstrate the incorporation. Could maybe map down to current
  pkgs.
* ordinary users must be able to install from pkgsrc into local
  environment
* global installations stay in sync with local installations (that
  is local installations are recorded too and bulk-updated on 
  post-install of an updated pkg) - allow user to insist on a given
  version.
* addon pkg authors must be able to rely on the structure being the
  same in the local and global environment (and not too different
  from the "/usr/local" situation)
* structure which is used in the sw pkg's addon pkg's distrubution
  should be followed.
* addon pkgs usually know to which main version it belongs (e.g. perl56 vs
  perl58), use that knowledge to create appropriate depends/conflicts with
  other 'flavors' of given addon (56<->58) and the right core (e.g. ->56),
  so that on update-time trt (tm) happens.

For the tcl package this would mean:

 + pksrc/lang/tcl/core

 move tcl into core

 + pkgsrc/lang/tcl/tclcl
 + pkgsrc/lang/tcl/otcl

 etc.

 pkgsrc/devel/tcl-tclcl -> pkgsrc/lang/tcl/tcl (link?)

It's more obvious with perl:

 + pkgsrc/lang/perl/core58
 + pkgsrc/lang/perl/core56
 + pkgsrc/lang/perl/Math/Bezier
 + pkgsrc/lang/perl/Math/BigInteger
 ...

Now imagine there's perl/core56 installed on a given system, and john doe
wants to write something which requires, say, Math::Bezier for perl. He
could always download the thing and install locally, but if there is a
global update for it, and it eventually goes into pkgsrc(*), the local
installation won't be updated. If the sysadmin installs a global (maybe
differently versioned) copy, some sw pkgs atm probably show lossage. John
Doe could also use pkgsrc as non-root, with tons of configuration stuff
he has to tweak. If you just wanna add two, three packages to the installation,
impracticable.

I don't have the make knowledge to do that on my own, and I don't have
too much knowledge of the existing stuff either, but this is yet another
thread on something which has addon pkgs, and I feel this is going to be
yet another non-satisying solution (if you think it is, read the paragraph
up there again and reconsider -- every say emacs lisp programmer is unix-savvy
enough to do that on his machine ? Would he care ? he would install as
root. But on a public machine ? What'd he do ? Right, use the sw pkgs native
addon pkg handling, thus breaking the system's access on it)

Well, maybe this could be of some use for those of you who know the innards
well enough. If it isn't, well, you just gotta wait for it. It'll be done
eventually, I promise! :) It's just this bugs me really, it's one of maybe
two areas pkgsrc doesn't satisfy me, and I think especially programmers would
love to see something like that :)

(*) this could probably done automatically. And more than latex has a ctan
like distr site whose addon pkgs could (maybe?) be automatically converted
into something pkgsrc-compatible.

-Martin