Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

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

Aleksey Cheusov <cheusov%tut.by@localhost> writes:

> On Wed, Oct 24, 2012 at 7:07 PM, Aleksej Saushev <asau%inbox.ru@localhost> 
> wrote:
>> 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.
>
> http://mail-index.netbsd.org/pkgsrc-changes/2012/10/23/msg080188.html
> (Registering CONFLICTS...)
> Please don't mention pkg_add again until you read and understand the above.

Yes, I have read it and understand all of it. It is another reiteration of the
same invalid arguments.

1. CONFLICTS is relevant only for source builds with non-staged and/or 
privileged
installation, when package can perform uncontrolled writes. Other corner cases
are so rare that I don't remember any. I don't know if Joerg can bring real 
examples,
and until he does, these cases are the only real reason why CONFLICTS exists 
still.

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;
b) they can just download all relevant packages and check them before 
installation;
c) they still have to download all relevant packages and check them anyway
to avoid problems in case of broken packages and/or summary database,
installation conflict checks are still needed for the same reason.

>> Given that in most cases one of conflicting packages is mostly unused one,
>> this is not a problem at all.
>
> This is very bad assumption. I *do* care about registering conflicts
> because I experienced problem caused by them a lot of times.
> In particular with LaTeX packages.

And this requires _manual_ conflict registration exactly _how?_

Last time I heard, you're running bulk builds. This requires way more
resources than owned by all those users that are allegedly affected by
the same problem. Those users still don't care enough to report though.

>> It is still not demonstrated why exactly you should put this database
>> into pkgsrc itself and kept manually there.
>
> You demonstrate again and again that you didin't read my emails at all.
> http://mail-index.netbsd.org/tech-pkg/2012/10/23/msg010266.html
> (Handling conflicting packages...)
> http://mail-index.netbsd.org/tech-pkg/2012/10/24/msg010270.html (What
> I'm trying to do...)

You demonstrate again and again the same invalid arguments.

> Just to make sure i'd like repeat once again that I'm very well aware that
> CONFLICTS can be generated automatically except cases Joerg said about
> (config files, files generated at installation time etc.).
> For generating them we can adapt bulk build tools.
> It's trivial but in this case we will be limited to
> conflictingpkg-x.y.z entries. This is bad.
>
> A better approach would be adding PLIST to pkg_summary(5) and delegate
> all required checks to nih, pkgin etc.
>
> Bulk build report is a wonderful thing for pkgsrc analysis.
> "Unregistered conflicts" is one
> example. Provided *all* CONFLICTS are registered manually and always
> kept up-to-date
> (i.e. no 900 lines of unreadable garbage) it allows to detect some
> sort of bugs as soon as they appear.

Again, you present the same invalid arguments.

What you're talking about imposes large maintainance burden
for miniscule gain at the price of hiding real problems.

What is more important, is that these checks have to be performed anyway,
and your meta-pkg_add still has to recalculate upgrade plan using real packages.

> Manual CONFLICTS: some amount of
> extra work -- yes; useful for detecting some sort of bugs -- yes;
> always up-to-date -- no but bulk builds help a lot to make it
> up-to-date. Auto CONFLICTS: extra work (pkg_summary += PLIST) -- no
> provided nih and pkgin already analyse PLIST; always up-to-date --
> yes; useful for detecting bugs -- no.

Here you demonstrate that the difference between manual conflict
registration and automatic checks is extra work and risk of being out-of-date.
One just has to read slightly more attentively or put it in table
(and correct some wishful thinking):

                         manual     automatic
extra work                yes          no
detecting some bugs       yes         yes
up-to-date                 no*        yes

* - yes, but with a lot of extra work.

This becomes worse if one adds more considerations which you omitted
(potential of hiding real problems within the code churn).


-- 
HE CE3OH...