George Georgalis <george%galis.org@localhost> writes:
> Thanks for the breakout, trying to work out the best way to smooth the
> ride. Indeed, I had a kernel derived 8.0 ${PKG_PATH}/pkgin and a
> personal pkgin configuration script hard coded the (7.0.2) repository,
> artifacts trying to reliably derive it in the past.
The pkgsrc/pkgin world expects a match between kernel, userland, and
built packages (and hence PKGPATH). Departing from that will cause
trouble....
> Today, an invalid repositories.conf.example is installed as part of
> pkg_add ${PKG_PATH}/pkgin
>
> ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/8.99.1/All
That sounds like a bug, and you can perhaps figure out where it comes
from and report it with a patch to fix it.
> Why? it is unclear when that repository would ever be valid. Could the
> pkgin install derive and setup a functional configuration, as a best
> (better) guess? Or, Is it possible to identify a PKG_PATH scheme that
> is reliable across the various (pre-)releases, at least for kernels
> that have compatible binaries available?
The approach seems to be to do this at build time. If pkgin while built
on 8.0_BETA produces a path of 8.99.1, that sounds wrong.
But the real issue is that for other than real releases, it's iffy if
there are packages.
In general, people not on releases probably have to pay attention to all
these details, figure out if there are packages, adjust the path, and be
careful. As always, patches weclome if you can smooth out rough edges
in a sound way.
Attachment:
signature.asc
Description: PGP signature