tech-pkg archive

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

Re: Time to change defaults for PKG_DBDIR



David Brownlee <abs%absd.org@localhost> writes:

> We have two older pkg_install variants - the original which will just
> unconditionally default to /var/db/pkg, and the current compat which
> overrides any PKG_DBDIR value if /var/db/pkg is present and PKG_DBDIR
> is not.

And those can be in /usr/pkg/sbin or /sbin.  It seems obvious that the
new behavior will not only be applied to pkgsrc and thus updated
/usr/pkg/sbin, but to the included copy in base and then pulled up to 8
and 9 (assuming this is done before 8 EOL, which seems likely).

> For the original the presence of an empty /var/db/pkg makes no difference.
>
> For the compat the only case I can see where erroring out on an empty
> /var/db/pkg could make a difference is where a new pkg_install is run,
> warns, the user to delete /var/db/pkg or set PKG_DBDIR, then at some
> point the user entirely deletes PKG_DBDIR and runs the older compat
> pkg_install - probably by nuking all of /usr/pkg and running the older
> pkg_install pkg_add to add a package. Note: this implies they have
> managed to get the initial new pkg_install installed the first time
> via a different method which did not trigger any issues.

Basically my view is that this has all been complicated and painful and
our ability to reason about it seems to have been outwitted by reality.
Hence, without accusing you of fuzzy thinking, I lean hard to simple
even if it is excessive.

> I'd really prefer to not have to force a new binary package user to
> read up about and then manually set PKG_DBDIR in pkg_install.conf when
> there are no binary packages on their system, however I don't want to
> block this any further, so while I'm listing my preferences in order,
> I'm happy as long as something is picked:

That's a good point; we do need to have an exit strategy.

> These would be new pkg_install behaviour if /var/db/pkg is present,
> _empty_, and different from the set/default PKG_DBDIR
> a) Try to rmdir/unlink (symlink) it, and continue if successful
> b) Ignore it and continue
> c) Error out the same as if present and non empty

I think you are laying out 3 options.

I like (a), with "if not successful, goto c".  That cleans up the
situation (perhaps with a message, perhaps not) and doesn't force a
failure.  Sounds like that option is reasonable for you and me?  Anybody else?

I think if we can do this, and ensure that all published bulk builds
with bad PKG_DBDIR settings are withdrawn, we may be able to stamp out
virtually all user trouble.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index