Repository navigation
/opt/local/sbin/pkg_alternatives: line 623: [: too many arguments #366
Description
Activity
That line is:
[ ! -f ${PKG_DBDIR}/${1}*/+ALTERNATIVES ] && \ err "no alternatives defined for the \`${1}' package"
That shell code isn't suitable for globs and should really be rewritten. I think the intention is that you should only be specifying a single package name (e.g.
go120, and the rest of it is happening by accident.FWIW on my macOS host:
$ pkg_alternatives status go pkg_alternatives: the package `go' is not known $ pkg_alternatives status go121 `bin/go' points to `/opt/pkg/go121/bin/go' candidate: /opt/pkg/go119/bin/go candidate: /opt/pkg/go121/bin/go `bin/gofmt' points to `/opt/pkg/go121/bin/gofmt' candidate: /opt/pkg/go119/bin/gofmt candidate: /opt/pkg/go121/bin/gofmt $ echo /opt/pkg/.pkgdb/go*/+ALTERNATIVES /opt/pkg/.pkgdb/go119-1.19.12/+ALTERNATIVES /opt/pkg/.pkgdb/go121-1.21.1/+ALTERNATIVES
i.e. I'm not getting the same error, so I guess there's an earlier check that is somehow passing for you.
On the smartos machine, there is a
gopackage, which is a meta for whatever is deemed the current release. That's probably what gets mine past the earlier checks.Oh ok, yeh those packages are fundamentally incompatible with
pkg_alternativesand I usually remove them completely from our package sets (e.glang/ruby). I think we decided to leave thegopackage as it was highly likely that people would want topkgin install go, but it does result in problems like this.That leads me to this question - there are a few other places, python is the one that comes to mind, where not being able to install one package name and get whatever is deemed current is a headache that leads to hardcoding versions in a bunch of playbooks, and the obvious downstream headache. Is there a better solution?
Personally I think the best solution is being specific about the versions you want to install. Yes this means you may need to update them every so often, but at least you are then explicit about opting into a new version that has been tested with the rest of your stack, and the versions aren't bumped all that often.
The alternative would be for me to provide e.g.
go-latest,python-latestmeta-packages that pull in the latest, but that wouldn't be without problems. For example the latest, i.e. newest, version may not be what pkgsrc is currently using as the default, and may not be suitable (e.g. say we import a new python312 but lots of modules aren't yet compatible with it and we keep the default at python311 for a reasonable length of time).One of the worst problems I have, which I end up fixing (it seems like) several times per year, is that the python offered on the gz tools platform only includes pip for one version. I never seem to notice in advance that an update to that is coming, and suddenly playbooks are crashing. So maybe the underpinning problem is that I need to figure out what to follow in order to know when to pre-emptively fix playbooks. There are a few other things that I retroactively discover -- I think the reason I have
goinstalled on this one system is that some combination of numbered go packages progressing, and rabid dependency updates in stuff Igo installkept driving me batty.Hmm, could you explain the pip issue a bit more? It looks like we don't ship pip in the gz tools set yet, so perhaps if we start doing that it should solve your issue.
Please make sure you raise issues for any problems that you hit, we want to be able to fix them!
Oh, ignore part of that - while we don't explicitly list
devel/py-pipin our tools builds, it does look like it's built as part of a dependency, and so yeh it will only be built for the current version of python (currently python 3.11).Ok I've added
devel/py-pipto the tools build, so now there are versions of pip for all available python releases:$ pkgin se py.*pip py310-pip-23.2.1 Installs Python packages as an easy_install replacement py311-pip-23.2.1 Installs Python packages as an easy_install replacement py38-pip-23.2.1 Installs Python packages as an easy_install replacement py39-pip-23.2.1 Installs Python packages as an easy_install replacementI think this should help with the issue you had?
Will definitely help. Thanks!
- added a commit that references this issue
on Feb 1, 2024 - added a commit that references this issue
on Mar 4, 2024 24 remaining items
- added 9 commits that reference this issue
on May 14, 2026 - added a commit that references this issue
on May 22, 2026
Various
pkg_alternativescommands generate an error. E.g.This seems to be related to there being nothing much in the database directory:
This even after a
rebuild.Have I managed to wound this machine's alternatives setup somehow?