Re: Asterisk package naming

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Aug 2,  7:24am, "D'Arcy Cain" wrote:
} On 2018-08-02 06:51 AM, Greg Troxel wrote:
} > D'Arcy Cain <darcy%NetBSD.org@localhost> writes:
} >> 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.
} 
} Hopefully once asterisk is gone we won't re-use the name.

     I have no intention of doing that.

} > 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.
} 
} Perhaps I haven't made it clear.  I am using this process to build many
} packages on one server to distribute across the rest of my network.
} Each server has its own file of packages that it wants which are
} gathered up by the build server, sort -u run on it and that is the file
} that is used in my chroot jail to build everything.  If this was just
} for asterisk or for a few packages it would be simple but I am trying to
} automate a larger system.

     I use dedicated VMs to build packages (one for each major
release).  I run pbulk on those VMs which ensures that all dependencies
are built and that packages are rebuilt when any dependency changes.
It also means that I get all variants of things like PHP with
corresponding modules since not all systems get updated at the same
time.  pbulk can be told to do a limited build.  For that it takes
a file containing a list of PKGPATHs.  I originally tried using
pkg_comp but I found that it didn't work very well for my purposes.
I then use pkgin for updating binary packages on other systems.

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

i386devel: {270} pkg_info -a | grep mysql
mysql-client-5.6.39 MySQL 5, a free SQL database (client)
p5-DBD-mysql-4.046  Perl DBI/DBD driver for MySQL databases
mysql-server-5.6.39 MySQL 5, a free SQL database (server)

} is no loop.  Asterisk is different in that the different versions get
} installed as asterisk and there is also a package called asterisk.
} 
} > We do not generally have meta packages to switch between multiple
} > versions, and I think they are more clutter than they help.
} 
} There probably aren't that many packages that could use something like
} this.  Offhand I can think of PostgreSQL, Python, Asterisk, Ruby and PHP
} from all of the packages that I install.

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

     I've been following this thread and letting it develop to see
where it would go without trying to influence it.  I think it has
pretty much come to a conclusion now, so it is probably about time
that I weighed in.  There were three main points.

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

     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.

     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.

}-- End of excerpt from "D'Arcy Cain"