[pacman-dev] File/Path locations

newer
Re: [pacman-dev] Pacman doesn't...

Andrew Fyfe

4 Jun 2007 4 Jun '07

11:26 p.m.

At the moment the file/path locations and where/how they are set is a bit of a mess, here's the idea I propose... Default locations set by configure: Root Dir : / DB Path : $localstatedir/lib/pacman Cache Dir : $localstatedir/cache/pacman/pkg Lock File : $localstatedir/run/pacman.lck Cfg File : $sysconfigdir/pacman.conf Pkg Ext : .pkg.tar.gz DB Ext : .db.tar.gz Source Ext: .src.tar.gz Where locations are set/overridden: Hard Code into pacman/scripts: - Cfg File Set in pacman.conf: - DB Path - Cache Dir - Lock File - {Pkg,DB,Source} Ext Override on cmd line: - Root Dir - DB Path - Cache Dir - Cfg File 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 Also to make the paths/locations available to scripts we could use iniread[1] written by James Rayner eg --- pacman.conf [options] dbpath = /var/lib/pacman --- makepkg.conf DBPATH=$(iniread /etc/pacman.conf options:dbpath) Thoughts, comments and ideas welcome. Andrew [1]http://tinyurl.com/2ex7du

Show replies by date

Andrew Fyfe

4 Jun 4 Jun

11:37 p.m.

We probably also want to add db/source checksum program to pacman.conf as well. Andrew

Dan McGee

5 Jun 5 Jun

1:18 a.m.

On 6/4/07, Andrew Fyfe 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. WRT the other stuff, everything is now configurable in either makepkg.conf or pacman.conf (with my next round of changes) and nothing is hardcoded anymore. The parameters you specify to configure will only be used to hard code the location of pacman.conf, and fill the defaults in pacman.conf. I don't see much behavior cleaner than this, and I don't want to draw another dep into pacman if we can help it. -Dan

Andrew Fyfe

19 Jun 19 Jun

8:05 p.m.

Dan McGee wrote:

...

On 6/4/07, Andrew Fyfe 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. Andrew

Dan McGee

10:03 p.m.

On 6/19/07, Andrew Fyfe wrote:

...

Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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 think so...why don't you just use a custom pacman.conf and put all the paths in there? pacman --config pacman.myconf -Dan

Aaron Griffin

13 Jul 13 Jul

4:13 p.m.

On 6/19/07, Andrew Fyfe wrote:

...

Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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?

Xavier

6:11 p.m.

On Fri, Jul 13, 2007 at 11:13:18AM -0500, Aaron Griffin wrote:

...

On 6/19/07, Andrew Fyfe wrote:

...
Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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?

I agree, this annoyed me too, I liked being able to just use -r for testing, now I have to use a custom config specifying all paths. However, I think Dan has a valid point that everything should be configurable. This wasn't possible before, was it? So, the question is : how do we make everyone happy ? It's probably possible, we just need to find out how ;) Could we just keep the old behavior, having the path specified in -r prefix all others by default, and this could be overwritten by specifying the other paths?

Dan McGee

6:19 p.m.

On 7/13/07, Aaron Griffin wrote:

...

On 6/19/07, Andrew Fyfe wrote:

...
Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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

Kevin Piche

16 Jul 16 Jul

6:28 p.m.

On Fri, 2007-07-13 at 14:19 -0400, Dan McGee wrote:

...

On 7/13/07, Aaron Griffin wrote:

...
On 6/19/07, Andrew Fyfe wrote:

...
Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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! :) IMHO -r should change all paths for general usage and the flexibility of Dan's approach would allow single paths to be overridden. k

Dan McGee

6:34 p.m.

On 7/16/07, Kevin Piche wrote:

...

On Fri, 2007-07-13 at 14:19 -0400, Dan McGee wrote:

...
On 7/13/07, Aaron Griffin wrote:

...
On 6/19/07, Andrew Fyfe wrote:

...
Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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?

...

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. -Dan

Kevin Piche

17 Jul 17 Jul

2:42 p.m.

On Mon, 2007-07-16 at 14:34 -0400, Dan McGee wrote:

...

On 7/16/07, Kevin Piche wrote:

...
On Fri, 2007-07-13 at 14:19 -0400, Dan McGee wrote:

...
On 7/13/07, Aaron Griffin wrote:

...
On 6/19/07, Andrew Fyfe wrote:

...
Dan McGee wrote:

...
On 6/4/07, Andrew Fyfe 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

6136

Age (days ago)

6179

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Aaron Griffin
Andrew Fyfe
Dan McGee
Kevin Piche
Xavier