David Brownlee <abs%absd.org@localhost> writes: > I think it is time to change the default PKG_DBDIR to $PREFIX/pkgdb rather > than the current transitional "use /var/db/pkg is present, else > $PREFIX/pkgdb" (First, this is I think only about NetBSD.) I have not really paid attention to the details of where we are now. I spent more time than I wanted to dealing with the fallout from the last change. Personally I have set PKG_DBDIR to /usr/pkg/pkgdb in pkg_install.conf pretty much everywhere. I am basically in agreement that it's been a long time in transition and that it's time to remove the transition mechanism. But I'm not sure that this is the only or main problem, if people are installing bulk builds with non-default PKGDB values. It may be reasonable to have the tools look for the configured PKG_DBDIR and also the other of /var/db/pkg or $PREFIX/pkgdb, and either warn or error out if both are present. To move forward, I'd suggest: Posting a complete summary of what's going on, perhaps on wiki.netbsd.org as I suspect that as we dig in it will get more complicated. In that, being clear about what is in the sources and what is in configuration of official build machines in terms of where pkgdb is, and configuration in mk.conf. posting a proposed patch if at all relevant, posting a proposed document that defines correct setup for official bulk builds. There is some text at http://www.pkgsrc.org/quarterly/ but it is more "if a bulk build with no changes fails, that means pkgsrc is broken", not "official bulk builds must not have non-default configuration". Finally, it's May in less than 12 hours, and it's getting close to branch (which will be my branch), and just before branch is not a good time to make changes. I don't mean to say that this is already precluded for 2022Q2, but e.g. late May is already not ok. If you mean to discuss and make a plan and do the commits after 2022Q2 is branches, that's fine, and if you mean before, then we should get going on this.
Attachment:
signature.asc
Description: PGP signature