-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 11 Nov 2004, Alistair Crooks wrote:

>Firstly, perhaps Jim could outline his views of how this will work,
>so that we can all be brought up to speed on his views.
>
>However, I believe that things have moved on since 1999, and
>pkg_install has grown a -K dir switch, primarily for package views. 
>What needs to be discussed is how to pick up the value of the metadata
>directory for the desired package collection, be it a package view,
>standard overwrite pkg installation, or system packages.  I know that
>I don't want to have to think about whether this is a system package,
>or what package view I'm in.  I don't want to specify that on the
>command line.  I want to specify it once, and then work with that view
>or installation.

Well, here's the main issue here, and I think it hasn't been changed 
much by the introduction of the -K switch:  novice users will want to be 
able to work with syspkgs in just as natural a way as they work with 
pkgsrc pkgs.  This can be achieved in two main ways:

  * syspkg and pkgsrc share a PKG_DBDIR -- this is obviously the
    simplest solution, but there was a lot of discomfort about this
    when it was first proposed.  The two main issues people had with
    this idea are that a.) it adds a _lot_ of syspkg names to the
    default output of `pkg_info', which people feel is confusing, and
    b.) it obscures the question of which packages come from pkgsrc
    and which from the base OS (though this is pretty clear from pkg
    naming).

    I have to admit that I don't find these arguments _very_ compelling,
    which is why I think we _should_ be revisiting the question of
    whether a separate PKG_DBDIR is needed for syspkg.

  * a flag to pkg_* indicates that you wish to work with syspkgs --
    this allows a user to quickly specify that the syspkg PKG_DBDIR
    should be used, without requiring novice users to remember (and
    specify each time!) the path to the syspkg PKG_DBDIR.  I feel
    (and others felt when this was last discussed) that requiring
    the user to set and unset PKG_DBDIR (and the same goes for
    providing a full argument to -K) each time will result in user
    error some percent of the time, with syspkgs and pkgsrc pkgs
    being cross-installed into each others PKG_DBDIRs, and other
    failure modes

Now, I myself slightly favor the first of these two options, but this 
was widely complained about in the first syspkg draft, so I'm not sure 
that this is the way we want to go.  Thoughts?


>It may be that a new switch is necessary, although I doubt this.  Does
>-X switch PKG_DBDIRs, does it override PKG_DBDIR in the environment,
>should we look at SYSPKG_DBDIR instead, should we provide syspkg_*
>commands, should we provide syspkg_* aliases in our standard shells,
>loads of questions.

My own feeling is that a separate variable, SYSPKG_DBDIR, should be 
overriding if -X is passed, and PKG_DBDIR should be overriding when it 
is not.  I think this is as far as we need go.


>I also had an idea about a separate utility which would stuff the
>value of PKG_DBDIR and/or SYSPKG_DBDIR into the environment, and which
>would be useful for package views as well.  Or pick up this value by
>searching the paths for a magic file in the first view directory for
>package views - would that be appropriate for system packages?

I like this idea _very_ much -- one of the goals of syspkg, which was 
never realized (yet) was to allow the admin to have separate 
SYSPKG_DBDIRs per-filesystem, so that if, for instance, an admin shared 
/usr from a central machine, /usr/pkgdb (or some such path) could 
contain the db of packages installed on that shared filesystem.

To support this goal, the syspkgs _have_ been designed such that no 
single package installs to more than one of /, /usr, and /usr/share, but 
the pkg db support hasn't been chased down yet.


>All feedback gratefully received.

Likewise!

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBk5gvpRpI6SYACmIRAjmyAKClePT2vxtU6jWV6ARa2Ac81PGmJACgqvEG
6EbspVLIboyeMS6D6BnSRQg=
=sjo6
-----END PGP SIGNATURE-----