Re: Asterisk package naming

[Greg Troxel <gdt%lexort.com@localhost>]

D'Arcy Cain <darcy%NetBSD.org@localhost> writes:

> On 2018-08-01 12:51 PM, Greg Troxel wrote:
>> It is very normal to have
>> 
>>   category/foo1
>>   category/foo2
>>   category/foo3
>> 
>> that all install the foo package of varying versions, with things named
>> foo, such that you can only install one of them.
>
> I have no problem with that scenario.  My problem is that asterisk does
> not match that pattern.
>
> comms/asterisk
> comms/asterisk13
> comms/asterisk14
> comms/asterisk15

True.  We also try not to rototill PKGPATH, because that causes trouble
(maybe for others, not you this time :-).  I have consistently asked
that packages be either single or all-versioned, with a very low rate of
changing back to single (because needing multiple is a long term stable
condition of an upstream...).  But some of this is very very old, and
it's unavoidably messy.

It seems comms/asterisk is EOL, and there are three new versions, but
I'll leave it to jenemeth to drop it because like postgresql and other
big systems, I know it's hard to update big installations across major
versions.

> So if my script tries to install asterisk13 it installs asterisk and it
> keeps trying to install asterisk13.  If it tries asterisk then I install
> an ancient version.

Why are you using PKGNAME rather than PKGPATH as the canonical list for
the script?  Or, why if you want to use PKGNAME, don't you build an
index from PKGPATH to PKGNAME, and find the best match?  Or just add a
table that maps the name to the version?  You have to choose between
11/13/14/15 somehow, and this really does not seem like a big deal.

> I understand that comms/asterisk will soon be removed so I will get that
> situation soon.  Meanwhile, I still think that a meta package for
> comms/asterisk that figures out which real package to depend on makes sense.

We do not generally have meta packages to switch between multiple
versions, and I think they are more clutter than they help.