On Mon, 2007-07-16 at 14:34 -0400, Dan McGee wrote:
On 7/16/07, Kevin Piche <kevin.piche@cgi.com> wrote:
On Fri, 2007-07-13 at 14:19 -0400, Dan McGee wrote:
On 7/13/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 6/19/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Dan McGee wrote:
On 6/4/07, Andrew Fyfe <andrew@neptune-one.net> wrote: > Default behaviour for 'pacman --root' > pacman --root /foobar > Root Dir : /foobar > DB Path : /foobar/$localstatedir/lib/pacman > Cache Dir : /foobar/$localstatedir/cache/pacman/pkg > > Lock File : /foobar/$localstatedir/run/pacman.lck > Cfg File : /foobar/$sysconfigdir/pacman.conf
This is a reply to the whole email, but I wanted to highlight stuff from above. This is no longer the case- I just eliminated this behavior. Every path is independent of the others. ROOTDIR is *completely* seperate now.
Sorry this is still bugging me, having to type 'pacman -r ... -b ... -c ...' is a pain in the ass. 99% of the time when I'm using 'pacman -r' I want the same fs layout with a different root dir prefix. Am I the only one that uses 'pacman -r' like this most of the time.
I actually might agree with Andrew here. Usually when I use -r, it's like "hey lets install bash in my homedir" or "lets make a chroot dir that I can use later". I want to use everything else the parent system has, as far as cache and configs go.
I dunno, what are all the use cases for using -r? Can someone list a use case where specifying all dirs is common?
Well my original thought was flexibility. Before you couldn't do some things that you can do now. Examples: 1. I want to build a chroot without doing crazy rsync/hardlinking of the pacman cache directory. 2. I want to make a more secure chroot. I don't want the pacman DB, cached packages, or the logfile in the actual chroot.
And before I made all these changes, I found it odd that the logfile was always specified with an absolute path but nothing else was.
To be honest, I'm not sure of all the use cases of --root. If anyone wants to chime in on this it would be appreciated.
-Dan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Dan,
Your item #1 can easily be accomplished using mount: mount --bind /var/cache/pacman/pkg chroot/var/cache/pacman/pkg
Don't forget to unmount before cleaning out your chroot environment! :)
Exactly. And is that easy to do in cygwin and/or on Dreamhost where I don't have root access?
You might with a cygwin mount command if MS can support a "mount --bind"-like operation but yes not having root may be a problem... :)
IMHO -r should change all paths for general usage and the flexibility of Dan's approach would allow single paths to be overridden.
I am starting to fall into this boat, where somehow -r should set defaults, but then they can be overridden. This could take a good amount of reengineering of the way we set up paths in both pacman and libalpm. I'd want to reimplement it different than before though, where it was snprintf-ing the two paths together in libalpm. We should be able to configure whatever we want, and we can let the frontend do the path concatenation if we need.
Should libalpm really setup paths or should a frontend be expected to provide all configuration? I'm not saying no sanity checks in the library to make sure the paths are directories and accessible just that pacman should pass a config struct with paths in it and libalpm should run with it. Or are you saying that libalpm sets up some paths and pacman others?
-Dan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
k