[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Merge of pkg_install-renovation
> 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
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
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?
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.
Main Index |
Thread Index |