Subject: Re: CVS commit: src/distrib/sets
To: Jim Wise <>
From: Daniel Carosone <>
List: source-changes
Date: 11/12/2004 08:41:12
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 11, 2004 at 11:51:20AM -0500, Jim Wise wrote:
> >On Thu, Nov 11, 2004 at 03:59:28PM +0000, Alistair Crooks wrote:
> >> 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.
> >
> >For benefit of the user experience, however we install system packages
> >it should feel nice and natural. Having a flag for it doesn't feel
> >nature to me.
> This sounds like an argument in favor of sharing a PKG_DBDIR between=20
> syspkg and pkgsrc.

I (in naive user mode) don't actally care where or what the package
system's private meta data is, and especially don't want to have to
tell the package tools this in order for them to work.  I want the
tools to take care of this for me.

I (in clever sysadmin mode) can certainly see strong arguments for
multiple DBDIR's, such as the shared /usr (or shared /usr/pkg!)
examples.  I can also predict potential problems where dependencies
exist between packages in different shared filesystems that can be
seen and manipulated only in part from different machines, and that
the tools will need to help me figure out what i've done wrong at

I (in concerned developer mode) am rather conscious of problems in
present pkgsrc that stem from over-encoding things like build and
dependency information into package names (currently done for binary
pkgs, mostly). Witness the plethora of basepkg-foo variants that
simply set some internal options and include
=2E./basepkg/Makefile.common.  Happily, pkgsrc is growing infrastructure
towards solving this problem, syspkg to me is threatening to be a much
worse offender with its highly encoded names.  This is a cheap and
quick approach, certainly, but ultimately a flawed dead end - there
are just too many permutations to try to encode into a name: versions,
dependencies, arch, build options, compiler flags and cpu-specific
output options, etc etc.  This sort of thing is a job for GUID's,
perhaps, not friendly names.

I (still in concerned developer mode) also see cases where pkgsrc
packages are used to replace or supplement basesrc packages, either
for additional functionality (postfix) or security updates
(openssh). There are currently cases where pkgsrc pkgs implicitly
depend on base system components that may get upgraded (openssl,
iconv..) that might benefit from being made explicit, we may evolve
cases where base components depend on pkgsrc components in some way.
While a good syspkg system will certainly help alleviate some of these
cases, new cases may emerge (perhaps PAM plugins?) and the pkg tools
need to help rather than hinder users in these cases.

I (in peanut gallery software designer mode) see the solution to all
of these problems taking a common shape.  Here's a sketch:

 - pkgtools look at multiple db directories and present the user with
   a consolidated view, perhaps in an analogous way that man(1) can
   look in multiple places for the documentation installed by those

 - pkg metadata allows many of the things people are trying to encode
   in names currently to be represented more appropriately and
   flexibly, whether via a rigid schema of structured data or a looser
   system of conventions around A-V tag pairs.
 - pkgtools have options to facilitate filtering and selection
   on this metadata (perhaps via a suitably-defined "package matching
   language" or consistent set of flags and options) that apply to all
   things I might want to do to packages: listings, deleting,
   resolving dependencies, finding binary pkg files, etc.  (Note here
   the deliberate implied potential for a db describing a set of
   binary pkg files for selection as potential install sources, at
   least as an optimisation over scanning each one of their contents
   each invocation, but perhaps also for publishing packages available
   remotely over http).

 - pkgtools have a way for the admin to record common/constant
   preferences that apply to such selections, so as not to have to
   keep repeating longer command lines. One example might be something
   like "only use binary packages compiled -march=3Dpentium3" vs "accept
   p3 or lower" (with the latter implied automatically on a p3
   machine, to prevent incompatible -march=3Dpentium4 or -march=3Dathlon
   packages getting installed, unless overriden say when installing a
   diskless root for a higher-rev machine).

 - package metadata filter syntax includes aliases or shorthand for
   common cases, such as "sys" for "(pkg.type =3D=3D syspkg) &&
   (pkg.dbdir =3D=3D $SYSPKGDB) && (pkg.installed =3D=3D TRUE) &&
   (pkg.installed.onhost =3D=3D $hostname)".  In most cases, these aliases
   are enough for most users, who don't have to learn too much more of
   the syntax (of which the above example is purely fictional).

 - package listing formats include columns for some of these metadata
   fields, and perhaps a ps -o like option for custom listings. As an
   overly simple example, Solaris pkginfo has a column for "system" or
   "application" (or some other values).

I (in running late for work mode) feel like I've said much of this
before, but hope it's useful and others agree.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)