Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

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

On Sat, Oct 27, 2012 at 9:35 AM, Joerg Sonnenberger
<joerg%britannica.bec.de@localhost> wrote:
> I have one
> installed already (*cough* the more common one like coreutils *cough*)
> and want to also install the second one (9base) now. Well, I am told it
> doesn't work. Let's spend a few minutes to figure out how to fix this.
> Well, this patch works. Let's install it the fixed package. Oh, crap.
> Doesn't work, I also have to fix and rebuild coreutils because someone
> was so helpful to make them mutally exclusive.

I don't think this is a serious problem. If you spent some time for patching
9base, it wouldn't be a big probem to also patch coreutils.
You spend much more time for fixing build failures. Avoiding conflicts is
relatively rare developer's activity.

As about mutual exclusiveness I have no strong opinion here.
From "fixing" point of view it's enough to register one-side conflicts.

> I know that coreutils and
> 9base have been adjusted in the mean time, but replace them with any
> other conflicting pair and the issue remains.

Take a note that these two concreate packages were fixed because
I analysed a list of unregistered conflicts and meaningly looked for unexpected
ones. You completely ignored the part of my email where I explained
why I prefer registering conflicts manually.

> I wouldn't be surprised if there can't be a single global database of
> known-to-conflict packages, built automatically e.g. on ftp.netbsd.org.

How many packages do you want to keep on ftp for this? 2011Q1?
2000Q1? What if a user patched the package and
bumped the package version by increasing pkgrevision?
(smart user like in your example about 9base vs. coreutils ;-) )?

BTW, you completely ignored the fact that manual conflicts are useful
not only for package management.

> Worst case is that a package manager can still just ask the user for
> revalidating the conflict by running pkg_info on the remote package,
> that doesn't fetch the whole package after all.

Oh, no. This is very bad way. pkg_summary(5) and (optionally) similar files
should be enough for package management.