[pacman-dev] permission/location for var/abs and cache/src
we still preset the values to /var/abs and /var/cache/pacman/{src,pkg} but recommend to use an unprivileged user for all that packaging stuff. this forces everybody to lower the directory permissions or raise the user up into a certain group or even give sudo permissions. i think adding a new group "packager" holding these directories could solve that. various options are possible. what's the best and most secure one? Andy
On 3/7/07, Andreas Radke <a.radke@arcor.de> wrote:
we still preset the values to /var/abs and /var/cache/pacman/{src,pkg} but recommend to use an unprivileged user for all that packaging stuff.
this forces everybody to lower the directory permissions or raise the user up into a certain group or even give sudo permissions.
No it doesn't. Like almost every config ever, if the user wants to change the value, they change the value. You *can* change the value - that's why it's there.
i think adding a new group "packager" holding these directories could solve that. This should be managed by the end user, not by us.
I don't understand this really - the commented value is the default value for the setting. This is fairly common (see, for instance, xine's config file). If you want it changed, you uncomment it and change it.
On Wed, 7 Mar 2007 19:32:40 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
I don't understand this really - the commented value is the default value for the setting. This is fairly common (see, for instance, xine's config file). If you want it changed, you uncomment it and change it.
Now here's something I never knew, and just found out poking around inside makepkg itself - it supports per-user configs. Make changes in ~/.makepkg.conf and bam - individual configuration. Slick. I was just about to comment how xine and other similar apps have per-user config, but I figured I'd look to make sure I wasn't talking out my ass when I was going to say makepkg didn't support that - good thing I checked. XD -- Travis
On Wed, 7 Mar 2007 21:56:20 -0500 Travis Willard <travisw@wmpub.ca> wrote:
Make changes in ~/.makepkg.conf and bam - individual configuration. Slick.
Oo, something I just noticed - devtools does _not_ support ~/.makepkg.conf - this needs to be fixed, since it looks for the package files in the directory specified and won't find them if they're specified in ~/.makepkg.conf. eg extrapkg will source /etc/makepkg.conf at the beginning but not ~/.makepkg.conf -- Travis
On 3/7/07, Travis Willard <travisw@wmpub.ca> wrote:
On Wed, 7 Mar 2007 19:32:40 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
I don't understand this really - the commented value is the default value for the setting. This is fairly common (see, for instance, xine's config file). If you want it changed, you uncomment it and change it.
Now here's something I never knew, and just found out poking around inside makepkg itself - it supports per-user configs.
Yeah, this is new. Maybe we should document it somewhere, don't know if it is in the NEWS file yet. And your other email about devtools- those just haven't been updated yet. Nor have many of the 'aftermarket' tools. Feel free to patch them and send it here, I'm sure you can pull the lines right out of makepkg. -Dan
On Wed, 7 Mar 2007 23:01:56 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
Feel free to patch them and send it here, I'm sure you can pull the lines right out of makepkg.
Right - somehow I didn't think to do this myself. Simple patch - everything symlinks to extrapkg in devtools, so extrapkg is the only one that needed a good patching. Here you are. -- Travis
On Thu, 8 Mar 2007 00:47:08 -0500 Travis Willard <travisw@wmpub.ca> wrote:
Right - somehow I didn't think to do this myself. Simple patch - everything symlinks to extrapkg in devtools, so extrapkg is the only one that needed a good patching.
Here you are.
And somehow.... I seem to have attached it twice. Ignore one of those, if you don't mind. ;) -- Travis
On 3/8/07, Travis Willard <travisw@wmpub.ca> wrote:
And somehow.... I seem to have attached it twice. Ignore one of those, if you don't mind. ;)
NO! I'm going to apply both. Hmmm "previously applied patch" what does that mean? /me commits it anyway
On Thu, 8 Mar 2007 09:36:45 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On 3/8/07, Travis Willard <travisw@wmpub.ca> wrote:
And somehow.... I seem to have attached it twice. Ignore one of those, if you don't mind. ;)
NO! I'm going to apply both. Hmmm "previously applied patch" what does that mean? /me commits it anyway
Actually, while I'm thinking about it - what's the desired behaviour for choosing the architecture when uploading packages? Should extrapkg look for all architectures in the arch=() array of the PKGBUILD, or just $CARCH, or $pkgname-$pkgver-$pkgrel-*.pkg.tar.gz, or something else entirely? Depending on the desired behaviour, I might be able to give you guys a patch for that tonight too. -- Travis
On 3/8/07, Travis Willard <travisw@wmpub.ca> wrote:
Actually, while I'm thinking about it - what's the desired behaviour for choosing the architecture when uploading packages? Should extrapkg look for all architectures in the arch=() array of the PKGBUILD, or just $CARCH, or $pkgname-$pkgver-$pkgrel-*.pkg.tar.gz, or something else entirely?
I was probably going to loop over the arch=() array, and send any and all built packages... it just seemed to make the most sense. If you have a better idea, let me know.
On Thu, 8 Mar 2007 09:54:34 -0600, Aaron Griffin wrote
On 3/8/07, Travis Willard <travisw@wmpub.ca> wrote:
Actually, while I'm thinking about it - what's the desired behaviour for choosing the architecture when uploading packages? Should extrapkg look for all architectures in the arch=() array of the PKGBUILD, or just $CARCH, or $pkgname-$pkgver-$pkgrel-*.pkg.tar.gz, or something else entirely?
I was probably going to loop over the arch=() array, and send any and all built packages... it just seemed to make the most sense. If you have a better idea, let me know.
Fair enough - that's what I assumed was best, just wanted some confirmation. I'll see about getting a patch in to the list in the next day or so. -- Travis
On 3/8/07, Travis Willard <travisw@wmpub.ca> wrote:
On Thu, 8 Mar 2007 09:54:34 -0600, Aaron Griffin wrote
On 3/8/07, Travis Willard <travisw@wmpub.ca> wrote:
Actually, while I'm thinking about it - what's the desired behaviour for choosing the architecture when uploading packages? Should extrapkg look for all architectures in the arch=() array of the PKGBUILD, or just $CARCH, or $pkgname-$pkgver-$pkgrel-*.pkg.tar.gz, or something else entirely?
I was probably going to loop over the arch=() array, and send any and all built packages... it just seemed to make the most sense. If you have a better idea, let me know.
Fair enough - that's what I assumed was best, just wanted some confirmation. I'll see about getting a patch in to the list in the next day or so.
I didn't implement the above looping stuff, but I left a nice note right where it needs to be done. :) Here is a patch for some other cleanup stuff in extrapkg if anyone is interested. <http://www.archlinux.org/~dan/extrapkg.patch> -Dan
On Thu, 8 Mar 2007 16:41:48 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
I didn't implement the above looping stuff, but I left a nice note right where it needs to be done. :)
Here you go - incorporating Dan's cleanup patch as well. This is a diff from the version of extrapkg patched with the minimal patch I double-attached previously. In the (limited) tests I've done with this, it seems to do the job. I've kept backward support for lack of -{$arch} suffix in for now, but it's easily enough removed. I pulled msg(), warning(), and error() from makepkg for it too, for consistency - I thought of this 'cause Dan's patch used 'error' in one place (copy-pasta probably) and I thought to myself "Meh, why not". If you'd rather the plain output I can put it back. :P -- Travis
On 3/9/07, Travis Willard <travisw@wmpub.ca> wrote:
On Thu, 8 Mar 2007 16:41:48 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
I didn't implement the above looping stuff, but I left a nice note right where it needs to be done. :)
Here you go - incorporating Dan's cleanup patch as well. This is a diff from the version of extrapkg patched with the minimal patch I double-attached previously.
In the (limited) tests I've done with this, it seems to do the job. I've kept backward support for lack of -{$arch} suffix in for now, but it's easily enough removed.
I pulled msg(), warning(), and error() from makepkg for it too, for consistency - I thought of this 'cause Dan's patch used 'error' in one place (copy-pasta probably) and I thought to myself "Meh, why not". If you'd rather the plain output I can put it back. :P
I threw this patch up at the same place my old one was with all changes from the SVN copy (revision 223). Here it is: <http://www.archlinux.org/~dan/extrapkg.patch>. Xentac, I believe this is your SVN repo? I CC'ed you in on this if you want to check this in, correct me if I am wrong. -Dan
On Sun, 11 Mar 2007 23:21:48 -0400 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 3/9/07, Travis Willard <travisw@wmpub.ca> wrote:
On Thu, 8 Mar 2007 16:41:48 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
I didn't implement the above looping stuff, but I left a nice note right where it needs to be done. :)
Here you go - incorporating Dan's cleanup patch as well. This is a diff from the version of extrapkg patched with the minimal patch I double-attached previously.
In the (limited) tests I've done with this, it seems to do the job. I've kept backward support for lack of -{$arch} suffix in for now, but it's easily enough removed.
I pulled msg(), warning(), and error() from makepkg for it too, for consistency - I thought of this 'cause Dan's patch used 'error' in one place (copy-pasta probably) and I thought to myself "Meh, why not". If you'd rather the plain output I can put it back. :P
I threw this patch up at the same place my old one was with all changes from the SVN copy (revision 223). Here it is: <http://www.archlinux.org/~dan/extrapkg.patch>.
Xentac, I believe this is your SVN repo? I CC'ed you in on this if you want to check this in, correct me if I am wrong.
-Dan
Yeah, I have a copy of the patch. I'm waiting for pacman to become official before applying it because the new -arch suffix isn't supported on gerolde yet (or most users' pacmans). Jason
On Wed, 2007-03-07 at 22:38 +0100, Andreas Radke wrote:
we still preset the values to /var/abs and /var/cache/pacman/{src,pkg} but recommend to use an unprivileged user for all that packaging stuff.
this forces everybody to lower the directory permissions or raise the user up into a certain group or even give sudo permissions.
i think adding a new group "packager" holding these directories could solve that.
various options are possible. what's the best and most secure one?
I'd like abs to read from ~/abs.conf and put files in ~/abs or similar. Shared src is less important in my opinion. Dale
participants (6)
-
Aaron Griffin
-
Andreas Radke
-
Dale Blount
-
Dan McGee
-
Jason Chu
-
Travis Willard