Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

["Filip Hajny" <filip%joyent.com@localhost>]

27. 10. 2012 v 18:41, Alistair Crooks <agc%pkgsrc.org@localhost>:

> There is now no reason to flag binary packages as conflicting.  The
> package managers should be smart enough to figure it out.  If they're
> not, then they need to grow the ability fast.  Installing a
> conflicting file over the top is not such a big deal as it was,
> because the original package is still around. But the problems with
> CONFLICTS entries is still around - they can grow stale, no-one checks
> them when packages change, etc.

I understand Aleksey Cheusov's main concern was that some binary packages are 
smart (or 'smart') and try to come up with an entire upgrade strategy that 
involves downloading a possibly large set of packages, and the strategy may 
turn out to be incorrect, because a PLIST conflict is found at installation 
time. I don't like extra CONFLICTS either, but I do understand his concern - I 
don't personally care about the extra downloads, but it's frustrating when the 
package manager can't actually figure out any better strategy, because it can't 
get the information it needs.

It's been mentioned that one way would be to maintain PLIST information in 
pkg_summary. I don't think that's a crazy idea to pursue, even though I 
entirely understand the file size concerns. Maybe a second (optional) file to 
hold this information that binary package managers could be taught to use? 
There's one great feature that pkgsrc would gain if package repository wide 
PLIST information was available - the package managers could search and install 
packages based on a file pattern.

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.

(I understand I'm getting slightly off-topic, sorry about that.)

-F