Open drboone opened 11 months ago
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 go
package, 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_alternatives
and I usually remove them completely from our package sets (e.g lang/ruby
). I think we decided to leave the go
package as it was highly likely that people would want to pkgin 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-latest
meta-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 go
installed on this one system is that some combination of numbered go packages progressing, and rabid dependency updates in stuff I go install
kept 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-pip
in 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-pip
to 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 replacement
I think this should help with the issue you had?
Will definitely help. Thanks!
Various
pkg_alternatives
commands 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?