Re: multiple version of packages with the same PKGBASE

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

> One of the current advantages of PKGBASE being the same (in the gqview
> case) is automatic CONFLICTS management.
Assigning correct CONFLICTS is done once and forever.
I guess many -devel packages are maintained by their maintainer
for a long time (emacs-current, for example).

 >> Ok. I see. You use PKGBASE+PKGPATH as a package "identifier".

> Well, PKGBASE and version identifies an instance of binary package, and
> PKGPATH ties that binary package back to the current source tree (or a
> newer binary bulk build) and thus a family of packages over time,
> leading to a rule about when an update is in order.

 >> I propose to use only PKGBASE. Because
 >> 1) PKGPATH is necessary only for source-based upgrades.
 >>    For binary upgrades it is easier to not check PKGPATH at all.
 >>    It is possible to check PKGPATH too, I don't see any reason for
 >>    this.

> With the current rules, it is necessary to look at PKGPATH to get what I
> consider the right behavior.  If you mean that it would be easier to
> change the rules, that's a more complicated judgement because there is a
> cost of change.
The only thing I propose is to keep PKGBASE unique in pkgsrc/ source tree.
I don't try to change a way source-based upgrades are done.
PKGPATH is still in binary package and...
Also pkg_rolling-replace, pkg_chk and all other package manipulating
programs are not affected. Everything will work as it did for years.
The cost of change is minimal.

 >>      pkg_online_client -i gqview
 >>
 >>    Instead of showing me information about ONLY ONE package I query,
 >>    it shows me information about three packages: graphics/gqview-gtk1,
 >>    graphics/gqview, graphics/gqview-devel

> So why is that bad?

Because I don't like it :-)
If I want to see all packages whose PKGBASE begins with gqview
I run pkg_online_find -i 'n:p:gqview'
(equivalent for pkg_online_find -i 'PKGNAME:prefix:gqview')

Server is online, you can try yourself.

Ok. I have another example from the third party world. My tool again :)

So, in order to keep pkg_online server always up-to-date
I need a tool that update source summary (see wip/pkg_src_summary) fast.
In short, source summary is in pkg_info -X format but contains
information about source packages a bit different fields (PKGNAME, etc.).

For this to work I'm developing tool wip/pkg_src_update_summary
(It is already ready and will be available soon).
It implements inremental approach.
Algorithm (in short):
based on microsummary collected by pkg_src_micro_summary (wip/pkg_src_summary)
(based on PKGNAME field)
full summary is collected for only updated packages.
"Updated" means new (first appeared or just absent in old source package
summary), upgraded, downgraded and surpise(!) those PKGNAME fields
are duplicated in the old summary. That is given two packages with
the same PKGBASE - gqmpeg I cannot say definitely should summary for it
be upgraded or not. Ok. I can use PKGBASE+PKGPATH again,
but this looks ugly :-(. So, I prefer to always update information about
them. I hope idea is clear.

 >>> This may be underdocumented, but I think it's pretty sane.
 >> This algorithm is trivial only for those people who name package using
 >> two instances ;) It think single PKGBASE is enough for most cases. The
 >> only reason to use additional PKGPATH is a source-based upgrades.

> Using source is a key part of pkgsrc, and any scheme has to work with
> both source upgrades and the results of bulk builds.  Certainly there is
> work to be done to make it better.
I have nothing against source-based upgrades. I only propose to change
thing that concerns binary package manipulation and some sort of third
party tools. Source-based updates will work just like as it does now.

> I don't understand why it's such a big deal to want to require PKGNAME
> to be unique, instead of taking PKGNAME and PKGPATH from an installed
> package to search for the pkgsrc source or pre-built binary package.
Just because too complex package identifier PKGBASE+PKGPATH looks
very ugly :( Details are are above.

-- 
Best regards, Aleksey Cheusov.