tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_install: move pkgdb under ${PREFIX}

On Fri, Aug 28, 2020 at 08:42:42PM -0400, Greg Troxel wrote:
> Thomas Klausner <> writes:
> > At the last pkgsrcCon (in 2019), pkgsrc-pmc decided to move the pkgdb
> > from its current default location (/var/db/pkg) to a location under
> > ${PREFIX}.
> Presumably you mean "in NetBSD, which is not bootstrapped".

True. We should make the bootstrapped installations use the same path
though, to reduce unnecessary differences.

> > Following prior art (jperkin's bulk build packages), I've used
> > ${PREFIX}/.pkgdb. Shortly after I made my patch, jmmv made a good
> > point about ${PREFIX}/libdata/pkgdb[1] in which he also made some good
> > arguments about the location under ${PREFIX}.
> One precedent is $prefix/pkgdb, in bootstrap.
> Another is $prefix/.pkgdb.
> I realize this is bikeshed territory, but:
>   I don't like libdata, because libdata should be things that are part
>   of packages and basically not changed (written at install of the
>   package that installs some files, and not changed otherwise).  This is
>   a database, not data for use by libraries.  Logically pkgdb belongs in
>   /var/db, per hier(7), and the problem with that location is that it is
>   logically connected to /usr/pkg, but not in it, which leads to
>   trouble.  And it is inconsistent in netbsd vs bootstrapped pkgsrc.
>   Therefore, it seems obvious that /usr/pkg/var/db/pkg or maybe
>   /usr/pkg/var/pkgdb is appropriate.  There is already use of
>   /usr/pkg/var/db.
>   I don't mind /usr/pkg/pkgdb, as this is putting it at top level but
>   it's also true that this is /usr/pkg metadata, not a database used by
>   packages.

I agree that this is technically a database, but it is a database that
is only changed when you do package maintenance, and not something
that changes because a user visits a webpage or runs a tool. That's
why I don't think it belongs into /var.

>   I don't like hiding it with ., as .pkgdb.  I think that's admitting
>   that it doesn't belong in /usr/pkg but that we put it there anyway.
>   (If it does belong, just call it pkgdb.  It's not like "ls -l
>   /usr/pkg" is often run, and that there is any value in hiding it.
>   Arguably, hiding it will confuse people more than it helps.)

I'm personally fine with libdata/pkgdb or pkgdb (or .pkgdb). I don't
care much either way.

> Overall, between my thoughts, precedent and other suggestions, I arrive
> at /usr/pkg/pkgdb.


> > For migration, I've made the pkgsrc infrastructure and pkg_install
> > stop in the revelant places to let the admin know that they should
> > move the directory to the new location (including the actual command
> > to execute: "mv /var/db/pkg ${PREFIX}/.pkgdb") to make it clear and
> > easy to fix.
> The patch does not change bootstrap; it seems obvious that pbulk
> defaults, bootstrap defaults, pkg_install defaults, netbsd base
> defaults, all have to match.

If I change the patch to use ${PREFIX}/pkgdb than bootstrap will
automatically match :)

I plan to update NetBSD-current once I've updated pkgsrc.

> The patch does not change the pkgsrc guide to explain this :-)

/var/db/pkg is not mentioned in the guide at all.  Perhaps we should
add an entry for the migration, but I think it's probably better put
in the wiki because it's a one-time change and not something you'll
need to use in your daily pkgsrc work.

> And how does this work with base system pkg_add?  Are you intending to
> request pullups?  How does that work with people who move to the branch
> with this change before or after updating along netbsd-8 or netbsd-9?
> I think we need a plan for the entire migration before this can go in.

When you keep on using binary packages only, you don't need to change
at all since the requirements for the pkg_install used by binary
packages has not changed (nor does it need to).

When building packages from source, NetBSD 8 and 9 will automatically
install the newest pkg_install from pkgsrc because the infrastructure
will require it.

Here's the only edge case that I can see: You will need to put
${PREFIX}/sbin before /usr/sbin in your package administrator (root)
PATH if you haven't done so already. You already should have done that
even now because requiring new package tools is something that pkgsrc
already sometimes does. (But only if you also build packages from

Since we can't change the old tools to check for the new path, we'll
have to add this in the pkgsrc release announcement (perhaps even for
the branch before the change) in a prominent place and send heads-up
emails to the mailing lists.


Home | Main Index | Thread Index | Old Index