postgresql packages, PG_SUBPREFIX and CONFLICTS

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

Hi. I recently commited the following

   http://mail-index.netbsd.org/pkgsrc-changes/2012/10/21/msg079998.html

and this commit raises a number for questions which should be discussed
in a wider audience. My goal is to make CONFLICTS entries in
pkg_summary(5) up-to-date for better work of binary package managers.

Please read the whole thread.

OBATA noticed that in postgresql90 there is a variable PG_SUBPREFIX that
changes the prefix for this package. He later proposed to either remove
PG_SUBPREFIX and register conflicts or to avoid them between postgresql
packages and remove all CONFLICTS. Personally, I don't have anything
against avoiding CONFLICTS in this case but I'm not willing to do this
myself. So, unless anyone do this, I'd like to completely remove
PG_SUBPREFIX and keep CONFLICTS up-to-date. At least for now. I'm fine
with either of these solution but reverting my commit, as proposed by
Joerg, doesn't make any sense because it doesn't introduce any
regression. It is correct.

Opinions?

2Joerg
>> Package conflict is a fact that is detected automatically already.

>This is not completely true. There is a valid reason for setting
>CONFLICTS if the overlap is in files that are not in the PLIST.
>E.g. if the only conflict is in configuration files etc.
>
>Use by pkgin is no justification, there could be a separate index
>computed for a set of binary packages that provides conflict hints.

Information about common files in packages can easily be gathered by
bulk build tools. I do this in distbb for debugging purposes. See

  
http://mova.org/~cheusov/pub/bulk/NetBSD/i386/5.1/2012Q3/logs/20121004.1013/META/check_unregistered_CONFLICTS.html

for example. Of course I'm able to use this list for enriching
pkg_summary(5) and forget about manually registering CONFLICTS forever.
However, this is not right way to go. Handling conflicting packages
*manually* allows us to find and fix *bugs* in pkgsrc. Some packages may
conflict by accident, for example, graphics/gimp-refocus-it
vs. graphics/refocus-it. I recent fixed them. Others may conflict
because they provide the same functionality and one should just be
removed, for example, audio/libmpg123 and audio/mpg123. Packages may
also conflict due to significant changes in upstream unseen by pkgsrc
developers. See, for example, devel/equeue and net/ocamlnet ocaml
packages. Nowadays equeque library is a part of ocamlnet and is not
provided as a separate package anymore. So, equeque package should just
be removed and textproc/harmony -- updated. One more bug I've found
while working with CONFLICTS. textproc/harmoby just cannot be built
because *both* ocamlnet and equeque are dependencies. An so on and so
forth.

-- 
Best regards, Aleksey Cheusov.