[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: postgresql packages, PG_SUBPREFIX and CONFLICTS
-------- 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
> > 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
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
Main Index |
Thread Index |