Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

[matthew sporleder <msporleder%gmail.com@localhost>]

On Sun, Oct 28, 2012 at 2:23 PM, Alistair Crooks <agc%pkgsrc.org@localhost> 
wrote:
> 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

I think the point of this was a database of all available package
files/PLISTs, even those which are not installed.

So if I wanted to find the 'git' package it could be recommended to me.

scmgit is a great example of a hard-to-find package.

--

FWIW I built a solr index of pkgsrc a little while ago and it would be
easy to add PLIST entries.

Matt