Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

[Aleksey Cheusov <cheusov%tut.by@localhost>]

On Wed, Oct 24, 2012 at 7:07 PM, Aleksej Saushev <asau%inbox.ru@localhost> 
wrote:
> And HOW EXACTLY does it present a problem to end user?
> This conflict shows up as soon as one tries to install one of packages.

http://mail-index.netbsd.org/pkgsrc-changes/2012/10/23/msg080188.html
(Registering CONFLICTS...)
Please don't mention pkg_add again until you read and understand the above.

> Given that in most cases one of conflicting packages is mostly unused one,
> this is not a problem at all.

This is very bad assumption. I *do* care about registering conflicts
because I experienced problem caused by them a lot of times.
In particular with LaTeX packages.

> It is still not demonstrated why exactly you should put this database
> into pkgsrc itself and kept manually there.

You demonstrate again and again that you didin't read my emails at all.
http://mail-index.netbsd.org/tech-pkg/2012/10/23/msg010266.html
(Handling conflicting packages...)
http://mail-index.netbsd.org/tech-pkg/2012/10/24/msg010270.html (What
I'm trying to do...)

Just to make sure i'd like repeat once again that I'm very well aware that
CONFLICTS can be generated automatically except cases Joerg said about
(config files, files generated at installation time etc.).
For generating them we can adapt bulk build tools.
It's trivial but in this case we will be limited to
conflictingpkg-x.y.z entries. This is bad.

A better approach would be adding PLIST to pkg_summary(5) and delegate
all required checks to nih, pkgin etc.

Bulk build report is a wonderful thing for pkgsrc analysis.
"Unregistered conflicts" is one
example. Provided *all* CONFLICTS are registered manually and always
kept up-to-date
(i.e. no 900 lines of unreadable garbage) it allows to detect some
sort of bugs as soon as they appear. Manual CONFLICTS: some amount of
extra work -- yes; useful for detecting some sort of bugs -- yes;
always up-to-date -- no but bulk builds help a lot to make it
up-to-date. Auto CONFLICTS: extra work (pkg_summary += PLIST) -- no
provided nih and pkgin already analyse PLIST; always up-to-date --
yes; useful for detecting bugs -- no.