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

Too late for what?

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

You confuse everyone by making it sound as if it is something catastrophic.

A system spending twenty more minutes downloading "a hundred of megabytes"
to find out that it just happened so that two little TeX packages conflict,
which happens once in years, and this system has to ask user for assistance.
This problem is so important that it must be solved by making multiple
developers follow constant code churn at risk of getting some wrong conflict
registered or not registered.

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

So, you mean that you support only cases when you have full control of
what's going on, is that right? What if there's a package that comes with
extra conflict? What if packages do not conflict any longer?

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

How long does it take to download several hundreds of megabytes?

Just to check that I have measured how long it takes on my slow line.

time ftp http://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0/iso/NetBSD-6.0-amd64.iso
Trying 2001:470:1f05:3d::21:80 ...
ftp: Can't connect to `2001:470:1f05:3d::21:80': No route to host
Trying 199.233.217.249:80 ...
Requesting http://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0/iso/NetBSD-6.0-amd64.iso
346052608 bytes retrieved in 38:20 (146.87 KiB/s)
     2302.48 real         0.47 user         3.48 sys

Thus a hundred of megabytes does take below twenty minutes of download time.

You make it sound catastrophic, but the reality is strikingly different.
In reality conflicts happen at much lower rate. Update itself takes longer too,
especially when it pulls in broken Cairo, crashing Firefox, Mplayer, VLC,
and semifunctional Emacs.

(It also takes longer even when goes smooth, since when you do have
a lot of those little TeX packages you complained of, it reruns mktexlsr
perhaps a thousand times, half a thousand for me currently.)

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

Never made a typographical mistakes in your life?

>> What is more important, is that these checks have to be performed anyway,
>
> No unless pkg_summary(5) is broken.

Consider it broken.
How long does it take for you to get all conflicts up-to-date?
Is it half an hour?

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

What if it is broken yet?
It doesn't sound like pkg_summary finds conflicts automatically.

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

Again, this is reiteration of the same claim of illusionary problems
supported with wishful thinking to make them sound as if they are real.


-- 
HE CE3OH...