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 > 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 least. 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 ../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 packages. - 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=pentium3" vs "accept p3 or lower" (with the latter implied automatically on a p3 machine, to prevent incompatible -march=pentium4 or -march=athlon 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 == syspkg) && (pkg.dbdir == $SYSPKGDB) && (pkg.installed == TRUE) && (pkg.installed.onhost == $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. -- Dan.
Attachment:
pgpRyJRRJ7jrL.pgp
Description: PGP signature