Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Wed, Oct 24, 2012 at 11:21:25AM +0200, Aleksey Cheusov wrote:
> 
> -------- 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.

Most of those conflicts are completely harmless. Others of your so
called bugs only don't show up in the bulk builds because they depend on
broken packages anyway. You have given no convincing argument AT ALL so
far. The reasons why nobody cares is a combination of it simply not
being a relevant problem and the general lack of attention to bulk
builds.

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

Neither pattern style works well. History *has* proven exactly that.
Your changes fail a simple maintainability check.

Joerg