Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

["Aleksey Cheusov" <vle%gmx.net@localhost>]

-------- Original-Nachricht --------
> Datum: Wed, 24 Oct 2012 00:19:36 +0200
> Von: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
> An: tech-pkg%NetBSD.org@localhost
> Betreff: Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

> On Wed, Oct 24, 2012 at 12:44:55AM +0300, Aleksey Cheusov wrote:
> > >> 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.
> 
> All this instances can be found and "fixed" without adding manual
> CONFLICTS.

No. Bugs I mentioned in the previous email existed
for years. For months "unregistered conflicts"
were available in distbb bulk builds for pkgsrcdevelopers and nobody cared.
I guess because there are so much bugs of this type in pkgsrc.
Analysing a list of unregistering conflicts consisting of alsmost 1000 pairs is 
a hard work. What I'm trying to do is
to significantly reduce this number, say, to few dozens of them for the 
beginning and then keep all conflicts under control.

> What you did is add yet another set of redundant entries that
> are highly likely to be outdated at some point without any indicator
> whatsoever that they are really needed.

No. As I said in the past every distbb report contains 
a full list of unregistered conflicts. Also, I'll add
additional check for "unnecessary conflicts". As soon as I do this and reduce a 
number of existing bugs, CONFLICTS will be under control. No chances for 
"outdated" and "without indicator".

> As such, it is obscuring the
> real cases.
> As such, IMO the correct way forward is to remove *all*
> CONFLICTS unless proven that they are required for dealing with issues
> outside the scope of the existing automatic check.

Obviously, there are cases when it makes sense to avoid conflicts between 
packages. I already said about 
gimp-refocus-it and refocus-it. These two were just packaged incorrectly.
Other examples are coreutils and 9base I changed in the past and different 
versions of emacs with all their modules (let's suppose for a moment that they 
have different PKGBASE). The same can be applied for postgresqNN packages. I 
can easily imagine usecases when they coexist on the same computer. But 
removing *all* conflicts is just impractical. Saying "remove"
I mean *avoiding* conflicts, not removing CONFLICTS variable from Makefiles.

As for automatic CONFLICTS generation. The only thing you can do in bulk build 
tools is to generate CONFLICTS-foo.x.y.z entries, neither -[0-9]* nor <=x.y.z. 
This approach is better than nothing but 1) cannot solve problems with binary 
upgrades in general 2) doesn't allow to fix bugs in pkgsrc, see above.

Auto-CONFLICTS can be viewed as an *addon* for manual CONFLICTS, not as a 
replacement.