Subject: Re: CVS commit: src/distrib/sets
To: Alistair Crooks <email@example.com>
From: Jim Wise <firstname.lastname@example.org>
Date: 11/11/2004 11:49:47
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----