Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

[Aleksej Saushev <asau%inbox.ru@localhost>]

"Aleksey Cheusov" <vle%gmx.net@localhost> writes:

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

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.
Given that in most cases one of conflicting packages is mostly unused one,
this is not a problem at all.

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

It's been years already and I'm still waiting for any user of Gambit Scheme
to show up and ask the question how to resolve the conflict. "Registering"
it in package source, in case you don't understand it, makes no difference
in user experience, since he cannot use both package simultaneously either way.

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

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

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

If these two packaged incorrectly then it is separate problem.
Thus this example is far-fetched at least.

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

Package names here demonstrate how relevant the problem is so that we
should definitly maintain all that conflict information in source.
While coreutils may be used, 9base is definitly the most used package ever.

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

This doesn't avoid conflicts since all these conflicts are detected at
the same time for binary packages and approximatly the same time when
building from source.

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

If your approach doesn't solve problems, then you should stop following it
and look for other solutions rather than rushing into manual registration
of package conflicts that are already detected by software. So far it obscures
_real_ problems when conflicts are not detected automatically.

For instance, you haven't provided an example how you're going to handle
conflict resolution. Example from my practice, MPICH2 (parallel/mpi-ch)
installs bin/mpd, thus it conflicts with lang/mpd. If someone renames
"mpd" of lang/mpd and forgets to remove conflict in otherwise unaffected
package, how is conflict resolution going to be detected?

Another example. The same MPICH2 installs bin/mpich-mpd and thus doesn't
conflict with bin/mpd installed by audio/musicpd. It lists conflict with
"musicpd-[0-9]*" nevertheless. Along comes Alexey Miusov who notices
that parallel/mpi-ch installed "bin/mpd" previously and now it doesn't.
Thus he removes the conflict. How, given the rate of changes with conflict
registration, does anyone detect whether mpich-mpd stopped using
configuration files named "mpd.conf" and ".mpd.conf"?

Advanced question. How relevant is the problem given that three packages
installing bin/mpd are:
1. MPICH2, which is software from high performance computing scientific
and engineering domains.
2. mpd, which is music playing daemon for geeks (not following desktop
standards of the day and thus a bit hard to integrate).
3. MPD, which is experimental programming language from the past.


-- 
HE CE3OH...