tech-pkg archive

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

Re: pkg_install: move pkgdb under ${PREFIX}

Thomas Klausner <> writes:

> On Fri, Aug 28, 2020 at 08:42:42PM -0400, Greg Troxel wrote:
>> 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.

Sure, but bootstrapping by default seems to use $prefix/pkgdb.  I
realize one can set it, but it's normal to not give args to set things.

> 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.

ok with me

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

I think we are more or less ending up that everything thinkgs that pkgdb
or .pkgdb is ok and more prefer pkgdb.

As for prior art, I see bootstrap defaults carry a fair bit of weight,
and joyent's choice not so much because that was one person using the
software, vs consensus (I don't mean to criticize it happening at all.)

>> 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 :)

That sound good.  Then NetBSD will match a default bootstrap on other
systems, and we'll have a single plan.  (Joyent can then adjust or not.)

>> 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.

Whatever is ok with me.  I think the guide ought to explain that there
is a db and where it is by default.

>> 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).

What I am concerned about is that soemtimes people have their PATH
backwards and run the base tools, and right now that is mostly ok.  We
therefore, I think, need a plan so that after migration things will be
in that same mostly ok state.   I think that involves adjusting -8 and
-9 base pkg_add, and more importantly the migration instructions saying
to move the database and symlink.  Then the base tools will be ok.

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

Yes, but a user that says "pkg_add foo" on a binary package and uses the
wrong pkg_add may have hard-to-figure-out trouble.

> 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
> source.)

Yes, it's true that you should.  I don't think it's true that it is
universally done.

> 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.

I think if migration has a symlink, perhaps even checked somehow
(new pkg_add throws a warning if not there?), that will avoid a lot of

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index