[pacman-dev] File/Path locations

[Kevin Piche]

On Mon, 2007-07-16 at 14:34 -0400, Dan McGee wrote:
> On 7/16/07, Kevin Piche <kevin.piche at cgi.com> wrote:
> > On Fri, 2007-07-13 at 14:19 -0400, Dan McGee wrote:
> > > On 7/13/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > > > On 6/19/07, Andrew Fyfe <andrew at neptune-one.net> wrote:
> > > > > Dan McGee wrote:
> > > > > > On 6/4/07, Andrew Fyfe <andrew at 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 at 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 at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev

k