Re: Merge of pkg_install-renovation

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> Hi all,
> unless reasonable objections are voiced, I plan to merge the
> pkg_install-renovation branch around the weekend.

> Major changes:
> - no more runtime dependencies on ftp or pax, pkg_install is essentially
>   self-contained
If I understand correctly using an external tool for downloading
will not be supported at all. Right?

> - x509 based signature validation for packages on both packages and
>   pkg-vulnerabilities for all systems with openssl in base (for those
>   without the question of static linkage needs to be addressed)
It is not clear for me what will happen to non-NetBSD system having _no_
openssl in base just after your merge.

> - pkg_add no longer extracts to /var/tmp, in-place installation is the
>   default
I personally whould prefer to change this default to old behaviour.
Is it possible? Is it possible to start unpacking after _entire_
binary is downloaded. Is it possible to set directory
for saving downloaded binaries there and to not remove binaries
after unpacking? I mean cache directory for binaries - this is how most
Linux distros work.

> - pkg_add/pkg_delete can deal with chroot-like subtrees. For full use,
>   +INSTALL/+DEINSTALL need to honour the PKG_DESTDIR environment variable.
Is there any documentation on this?  Will this change support run
pkg_add/delete fully unprivileged?  I ask because I'm interesting in
running _fully_ unprivileged DESTDIR bulk builds. That is
not only unprivileged building and packaging
but 'make depends' and 'make deinstall'.
Inside chroots pvivileges for /usr/pkg is not a problem.

> - automatic detection of conflicts based on +CONTENTS
Wow. Suppose conflict is detected. What happens then? Exit with error
or just a warning message?

P.S.
Another questions about pkg_add.

Current version of pkg_add works incorrectly in case of unpacking
failure. That is new package is registered in pkgdb with no any
changes in /usr/pkg. Is this bug fixed/tested?

I personally whould prefer to see pkg_add as atomic operation. That
is, pkg_add which either _fully_ succeeded or failed. In case of
failure old files should be kept intact and old package should be
registered in PKGDB. Is this already done or planed?

-- 
Best regards, Aleksey Cheusov.