Re: Asterisk package naming

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

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

> The point of my script is to not have to handle 1048 packages
> distributed to multiple servers by hand.

sure, that makes sense.

> I am not generating a list from what is installed.  I am creating a list
> of what I want to be installed.  Sometimes I need to remove a bunch of
> packages because pkg_rolling-replace doesn't handle dependencies
> correctly.  I then have to remove a package so that I can install the
> correct version.  Sometimes that means removing a bunch of packages that
> I still want.  I then have to run my script to see what's missing.

So somehow, you need to have a file that (more or less) has one line
describing every package you want installed, per machine, and then to
cat/sort/uniq these to run your bulk build.  Apparently that file right
now has PKGNAME in it, and your bulk build script tries to convert those
to PKGPATH..  That is basically troublesome, and we are suggesting that
instead you have control files that have PKGPATH instead.

>>> Yes, sometimes the guess will fail but except for asterisk it always
>>> fails by installing nothing and I can handle it manually.  Except for
>>> asterisk once everything is installed my script does not complain about
>>> anything.
>> 
>> Once you move to PKGPATH, I think you'll be ok.
>
> How?  Did you follow my examples?  PKGPATH may even work for other
> packages but not for asterisk until comms/asterisk is removed.

If you want asterisk 1.5, then just put

comms/asterisk15

in your file that has a list of PKGPATHs.  I mean to specify the path to
the directory to build, not the package name, so no magic is necessary.

If you want to have a list of PKGNAME, then you are going to be pushing
wet noodles uphill until you have completely reinvented pkgin (which
might do what you want if you stop insisting on having a list of
PKGNAMEs).

pkgsrc has an implicit mapping between PKGNAME and PKGPATH, and this is
I believe in pkg_summary, and used by pkgin.  Trying to write ad hoc
rules that guess intead of computing and using and actual mapping is
just going to cause pain.


And if your only real problem is the existence of comms/asterisk, could
you just put a special case in your script?  That seems faster than this
discussion.