Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Oct 28, 2012 at 10:48:42AM +0100, Marc Espie wrote:
> On Sun, Oct 28, 2012 at 10:42:54AM +0100, Filip Hajny wrote:
>  
> > That's a request we have received many times from our cloud
> > customers.  They are not familiar with pkgsrc, look for particular
> > tool, and don't know which package has it.  While some of these
> > case are arguable ('gmake' vs.  'make'), some others are entirely
> > valid (e.g.  why there is 'mercurial' and monotone', but 'scmcvs'
> > and 'scmgit'?).  If e.g. pkgin could suggest package names based
> > on PLIST entries, that would be great.

Yeah, we've had this since 1999/2000:

% pkg_info -Fe /usr/pkg/bin/gmake
gmake-3.82nb2
%

but the lack of partial matching is a PITA. We should look at providing
that. Also, IIRC, it's case sensitive, which used to be a problem for me
with things like Mesa and friends.
 
> That's a common issue to all packaging systems. If you have a reliable way
> to obtain PLIST information, you can easily build a database from it.
> 
> We did that in OpenBSD, and now we have a locate(8) database of all files 
> in all packages, prepended with the package name.
 
Interesting that OpenBSD decided to go their own way about things.

> Hooking that to various tools is not too difficult. It's also possible to
> simply advertize on it, so that people may choose to start with that
> specific package, then get whatever file they want.
> 
> Any database format will do, but locate(8) is very suitable for that since
> its compression scheme was more or less designed for that.

The problem with the locate database, as with others built from installed
packages, is that it doesn't relate to files with the same name from packages
which are not installed locally, which means that for the purposes of this
discussion, i.e. CONFLICTS entries, it's useless.

For standard uses, there's also the timelag before locate.updatedb(8)
is run again, along with what happens when packages are deleted and
their entries are no longer.  But yes, it's a nice idea, just not
really meant for what you want it for.

Oh, and for standard locate entries, "locate gmake" on NetBSD (amongst
other platforms) produces a number of hits from the tools build from
the cross-build infrastructure, so that locating the package name for
the file system entry would be difficult, if not impossible.

e.g.

% locate gmake
...
/usr/src/gnu/dist/gmake/w32/subproc/misc.c
/usr/src/gnu/dist/gmake/w32/subproc/proc.h
/usr/src/gnu/dist/gmake/w32/subproc/sub_proc.c
/usr/src/gnu/dist/gmake/w32/subproc/w32err.c
/usr/src/tools/Makefile.gmakehost
/usr/src/tools/gmake
/usr/src/tools/gmake/CVS
/usr/src/tools/gmake/CVS/Entries
/usr/src/tools/gmake/CVS/Repository
/usr/src/tools/gmake/CVS/Root
/usr/src/tools/gmake/CVS/Template
/usr/src/tools/gmake/Makefile
%

and, in general, as a file -> package name database, well, there's a
fairly substantial bit (like the result) lacking, n'est-ce pas?

I'm obviously missing something.

Regards,
Alistair