If your point is that this is too trivial to waste more time on, then
c'est la vie. But just in case you also think you are right:
It's simple. PKG_CACHE is a parameter to pkg_add. If you run other
options, like -n or -s, there is an obvious interface conflict. What
should pkg_add obey ?
I object to the silent part... if you're trying to actually use PKG_CACHE
then, having it fail silently and then discovering several GB later that oops,
it didn't save anything anywhere looks like a huge mistake.
But I'll try to make the error message be completely explicit.
Sorry! My email was garbled: a combination of a failure to refresh the
screen and no morning coffee. Here it is again:
I disagree that pkg_add should always error out when PKG_CACHE is
unwritable. Specifically, when pkg_add is invoked with the -s option, no
package is copied to the package
On Mon, 13 Jul 2015, li...@wrant.com wrote:
I object to the silent part... if you're trying to actually use PKG_CACHE
then, having it fail silently and then discovering several GB later that
oops,
it didn't save anything anywhere looks like a huge mistake.
But I'll try to make the
On Mon, Jul 13, 2015 at 12:21:07PM -0600, Dale Lindskog wrote:
On Mon, 13 Jul 2015, li...@wrant.com wrote:
I object to the silent part... if you're trying to actually use
PKG_CACHE
then, having it fail silently and then discovering several GB later that
oops,
it didn't save
On 2015-07-06 Mon 23:08 PM |, Chris Bennett wrote:
If you want to have a writable PKG_CACHE, why not do something simple
like /home/dude/pkg_cache?
$ printenv PKG_CACHE
/var/cache/pkgs
$ ls -lod /var/cache /var/cache/pkgs
drwxr-xr-x 8 root wheel nodump 512 May 28 21:57 /var/cache/
On Mon, Jul 06, 2015 at 07:15:06PM -0600, Dale Lindskog wrote:
It is discouraged but possible to run pkg_add(1) with -n or -s as a user
other than root. However, if pkg_add(1) does not have write permission to
$PKG_CACHE, then unclear error messages are produced. For example:
$ ls -ld
On Mon, Jul 06, 2015 at 10:15:20PM -0600, Dale Lindskog wrote:
On Mon, 6 Jul 2015, Chris Bennett wrote:
If you don't have root access, should you really be installing packages?
It is impossible to install packages when you are not root. pkg_add won't
let you.
This isn't about
It is discouraged but possible to run pkg_add(1) with -n or -s as a user
other than root. However, if pkg_add(1) does not have write permission to
$PKG_CACHE, then unclear error messages are produced. For example:
$ ls -ld $PKG_CACHE
drwxr-xr-x 2 root wheel 3072 Jul 2 12:13 /var/pkg_cache
You're right, this most probably needs a fix.
However, if pkg_add(1) does not have write permission to
$PKG_CACHE, then unclear error messages are produced.
So, there is an error which makes you think.
You notice and consider something is not that right, then go to address
the issue.
In the
On Tue, 7 Jul 2015, li...@wrant.com wrote:
One solution is for pkg_add(1) to silently omit the attempt to copy
the package to an unwritable $PKG_CACHE.
The end result with the change proposed would be to hide the problem you
have with permissions for $PKG_CACHE. In the end you will not
On Mon, 6 Jul 2015, Dale Lindskog wrote:
I confirmed also that Perl's '-w' returns true on a directory even when
write permission is completely removed from that directory.
I should have said:
I confirmed also that, *when the Perl program is run by root*, Perl's '-w'
returns true on a
On Mon, 6 Jul 2015, Chris Bennett wrote:
If you don't have root access, should you really be installing packages?
It is impossible to install packages when you are not root. pkg_add won't
let you.
This isn't about installing packages without root access. This is about
the -n and -s
On Mon, Jul 06, 2015 at 07:15:06PM -0600, Dale Lindskog wrote:
It is discouraged but possible to run pkg_add(1) with -n or -s as a user
other than root. However, if pkg_add(1) does not have write permission to
$PKG_CACHE, then unclear error messages are produced. For example:
$ ls -ld
14 matches
Mail list logo
