tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pkg_add functions and renovation
Hi all,
I'm working on large patch to switch pkg_add completely to libarchive
and libfetch. Code is promising and pkg_add has gotten a lot faster.
This has a number of implications on the functionality though.
(1) pkg_add -R is currently enabling -I as well (no register -> don't
run install scripts). The problem is here that I would have to create
and remove a temporary directory as I can't run it in the normal pkgdb
directory. I am not sure if anyone is even using -R, so I am not sure if
this is a relevant regression.
(2) pkg_add - is currently not supported. Does anyone really use it?
(3) pkg_add -s is somewhat challenging as it makes problems with the
unified remote/local code. It means I would have to go back and figure
out if it was a local file etc. I would disable this function for now
and provide a replacement later. An idea that doesn't conflict with
streaming installation is to wrap the package in another tarball. You
create a hash of every 16KB or whatever block of the real package, sign
the list of hashes and include the signed hashes and the package in the
tarball. An invalid block hash would be handled like a read error and
result in a cancelled installation.
(4) @chmod is missing right now as parsing the permissions is
non-trivial. What should it support -- the full syntax of chmod? In that
case I would call the real chmod for each file with a @chmod entry.
The other question is whether the file should be extract with minimal
permissions or not. E.g. if @chmod a+x is valid.
(5) I had to discover a bug in pkg_create when it comes to hardlink
creation. nbpax currently ignores the permissions for the second entry,
which is not correct. I am not sure if I want to work around this or
not.
Other than that the code needs more work in the error recovery
department, I will commit it to a branch soon.
Joerg
Home |
Main Index |
Thread Index |
Old Index