Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

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

On Wed, Oct 24, 2012 at 9:39 PM, Aleksej Saushev <asau%inbox.ru@localhost> 
wrote:
> Aleksey Cheusov <cheusov%tut.by@localhost> writes:
> 2. Registering conflicts doesn't help binary package managers "to build 
> update plan"
> since: a) the upgrade plan almost never includes packages that might conflict;

No. I already said that this is not true. You always ignore everything I wrote.
This style of discussion is absolutely useless.

> b) they can just download all relevant packages and check them before 
> installation;

As Jeremy said it is too late. If necessary checks are made "just
before installation",
that is, after downloading binaries and problems were found,
then "update plan is bad, nothing can be done". Period.

> c) they still have to download all relevant packages and check them anyway

What kind of checks?

> to avoid problems in case of broken packages and/or summary database,

Broken packages? LOL

> installation conflict checks are still needed for the same reason.

No.

In order to avoid updates stopped in the middle due to pkg_add failure
my "nih" does additional checks for conflicting packages because our
pkg_summary(5) is always broken and incomplete.
From time to time it says "Sorry, man. Your pkg_summary(5) is broken.
I built update plan for your and according to pkg_summary(5) everything was
fine. Unfortunately after download of several hundreds of megabytes
I've found a number of unregistered conflicts between packages. So,
your system cannot be updated. Blame pkgsrc developers.
Their system is borken"

> And this requires _manual_ conflict registration exactly?

No. Reread everything I wrote once again and _try_ to understand it.

> What you're talking about imposes large maintainance burden for miniscule gain

No. Some amount of work is needed and *I* will do this.

> at the price of hiding real problems.

Reality is opposite to this statement. Registering CONFLICTS
automatically "hides the real problems". What I'm trying to do
is to keep all conflicts under control. New conflicts may appear due to
bad packaging. I'd like to track them all. Manually!

> What is more important, is that these checks have to be performed anyway,

No unless pkg_summary(5) is broken.

> and your meta-pkg_add still has to recalculate upgrade plan using real 
> packages.

No. You just don't understand how it works. pkg_summary(5) is/should
be sufficient.

> detecting some bugs       yes         yes

No. You missed the point. Reread again.

> up-to-date                 no*        yes
>
> * - yes, but with a lot of extra work.

Incorrect. See above.