tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Asterisk package naming



On 2018-08-03 02:32 AM, John Nemeth wrote:
> On Aug 2,  7:24am, "D'Arcy Cain" wrote:
> } Hopefully once asterisk is gone we won't re-use the name.
> 
>      I have no intention of doing that.

OK, I thought that someone said that it was being dropped soon.

> } currently build Python 3.6 so my script and /etc/mk set Python variables
> } to "36".  However, the package gets installed as python36-x.x.x so there
> 
>      This is likely due to the fact that it isn't uncommon to have
> multiple versions of python installed at the same time.  It is very

postgresql95-client-9.5.13 PostgreSQL database client programs

PostgreSQL cannot install multiple versions.

> unlikely that somebody would want to install multiple versions of
> Asterisk at the same time.  BTW, MySQL is an example of a multi-version
> package which doesn't install with the version as part of the
> PKGNAME, i.e.

$ ls -ld /usr/pkgsrc/databases/mysql-client
ls: /usr/pkgsrc/databases/mysql-client: No such file or directory

Unlike Asterisk:

$ ls -ld /usr/pkgsrc/comms/asterisk
drwxr-xr-x  5 darcy  wheel  512 Jul 20 04:37 /usr/pkgsrc/comms/asterisk

There may be other packages like Asterisk in this regard but I haven't
tripped over them.

>      The only precedent that I could find is editors/emacs.  And,
> that was likely done because there are a crapton of emacs "modules".

So there is a package with a meta version for selecting the preferred
version.  I thought someone said that we don't have any.

>      The first point is about creating a meta-package with a default
> version.  The problem with this is, at what point do I change the
> major version that the meta-package installs?  This could lead to
> a crapton of debates that I'm really not interested in.  Secondly,

I would assume that it would always be the current LTS.

> there doesn't seem to be much in the way of a precedent for this
> idea.  For those two reasons, I'm not inclined to do this.

That's fine.  I gave up on that proposal a while ago.

>      The second point is the idea of having the PKGNAME contain
> the major verion of the package.  There is no clear precedent here
> as there are a number of packages that install both ways (comms/emacs,
> the only meta-package I found, installs without the major version).
> I'm certainly not going to change any existing package as that
> would lead to a nasty violation of POLA.  I pondered the idea for
> future versions.  However, it seems that the main driver behind
> the request is one person's broken script and nobody else has spoken
> up in favour of the idea.  That's not really a strong reason for
> making a significant change that could surprise people and could
> cause other people problems as they would have to always remember
> to use the major version when trying to do anything with the
> installed package.

My point is that asterisk stands alone in our package system this way,
Every other package with multiple versions either has a meta version,
has the version in PKGNAME or has no package with the un-versioned name.

>      The third point was about when comms/asterisk would be deleted.
> Shortly after the last quarterly release I added some security
> patches that were missing.  I'm going to wait until at least the
> next quarterly release before deleting it so that the final version
> will be included in a release.  At that time, it would be approximately
> one year past EOL.  I think it would be reasonable to put out a
> query and see if anybody has an objection to deleting it.  So, the
> short answer to the question is likely early next quarter.

And I will continue to handle asterisk manually until then rather than
making my script more complicated for the sake of one package.  Can we
at least agree that once asterisk is EOL'd we won't create another
un-versioned asterisk in the future?

-- 
D'Arcy J.M. Cain <darcy%NetBSD.org@localhost>
http://www.NetBSD.org/ IM:darcy%Vex.Net@localhost


Home | Main Index | Thread Index | Old Index