Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

[Marc Espie <espie%nerim.net@localhost>]

On Sun, Oct 28, 2012 at 07:23:28PM +0100, Alistair Crooks wrote:
> 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.

Well, not wanting to be rude, but our packaging systems have hugely diverged
years ago. We've had binary packages and package updates long before pkgin 
came into existence.

Too bad you didn't come and talk with me at eurobsdcon, might have been 
interesting.

> > 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.

Nope. You're totally wrong. You are making an assumption on the ways locate
is built.

You can create a locate-style database from anything, including non-installed 
packages.  You pretty much create your list of files, find-like, and feed 
it to mklocatedb.

So we are using the meta-information of all packing-lists, and we've taken
great care to make certain this meta-information is accurate for all packages,
even on architectures where some stuff does not build (dynamic plists are evil
and we don't use them, specifically for THAT reason).

Specifically, we have a reasonably small perl utility, pkg_mklocatedb
that exists in /usr/src/usr.sbin/pkg_add and reads the packing-lists from
make print-plist from a set of ports.

Up until around 5.1, we did use the standard SUBDIR list from ports.
Recently, we switched to using sqlports, since it does a transitive closure
on that, which means we also get ports and flavors not directly linked to the
tree, but still reachable through dependencies.

> 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.

Funny, I don't seem to have that problem :)

echo$ pkglocate gmake
a2ps-4.14p5-a4:print/a2ps,a4:/usr/local/share/a2ps/sheets/gmake.ssh
a2ps-4.14p5:print/a2ps:/usr/local/share/a2ps/sheets/gmake.ssh
gmake-3.82p2:devel/gmake:/usr/local/bin/gmake
gmake-3.82p2:devel/gmake:/usr/local/info/make.info
gmake-3.82p2:devel/gmake:/usr/local/man/man1/gmake.1
gmake-3.82p2:devel/gmake:/usr/local/share/locale/be/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/da/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/de/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/es/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/fi/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/fr/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/ga/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/gl/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/he/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/hr/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/id/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/it/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/ja/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/ko/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/lt/
gmake-3.82p2:devel/gmake:/usr/local/share/locale/lt/LC_MESSAGES/
gmake-3.82p2:devel/gmake:/usr/local/share/locale/lt/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/nl/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/pl/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/pt_BR/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/ru/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/sv/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/tr/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/uk/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/vi/LC_MESSAGES/make.mo
gmake-3.82p2:devel/gmake:/usr/local/share/locale/zh_CN/LC_MESSAGES/make.mo
mrtg-2.17.4:net/mrtg:/usr/local/bin/cfgmaker
mrtg-2.17.4:net/mrtg:/usr/local/man/man1/cfgmaker.1
ngspice-22:cad/ngspice:/usr/local/bin/ngmakeidx

That's on a system that doesn't have any of these built nor installed, btw.

> I'm obviously missing something.

Heh. ;)