Hey folks, this mostly works like it should. I tested it on an fc3 system and a rawhide system with some success.
let me know what does not work on your systems.
The config file stuff could use some love, of course.
http://linux.duke.edu/~skvidal/RPMS/mach/
you need to make one change to the default config file:
/etc/mach/conf
change: config['defaultroot'] = 'fedora-3-i386' to: config['defaultroot'] = 'fedora-development-i386-core'
then run:
mach setup mach rebuild /my/favorite/srpm
and read the output.
see if it works for you.
-sv
On Mon, 2005-02-28 at 18:03 -0500, seth vidal wrote:
this mostly works like it should. I tested it on an fc3 system and a rawhide system with some success.
Oooh, pretty. And a step in the (right) direction of getting to a working buildsystem.
mach setup mach rebuild /my/favorite/srpm
and read the output.
see if it works for you.
Seems to work okay in some quick testing on a rawhide i386 box. anaconda built fine. On the other hand, the mach package is missing a buildrequires on libselinux-devel ;-)
If I'm not snowed in tomorrow, I'll try to do an install on an x86_64 box and see how things go there.
Jeremy
Seems to work okay in some quick testing on a rawhide i386 box. anaconda built fine. On the other hand, the mach package is missing a buildrequires on libselinux-devel ;-)
If I'm not snowed in tomorrow, I'll try to do an install on an x86_64 box and see how things go there.
I installed on an x86_64 box. FC3 but made an installroot of rawhide. The installroot works fine - but rpm commands flake out when you run them from the outside of the chroot. Oddly yum --installroot commands work just fine from the outside.
anyway - if we run on the same rpm version we're building for it shouldn't be a problem. I'll install the other opteron tomorrow and see if I can get a mach x86 chroot running on x86_64 w/setarch reasonably sanely.
if we can get there then maybe a mass rebuild can be:
for pkg in * do if [ -d $pkg/devel ]; then make srpm fi done
find ./ -name *.src.rpm | xargs mach rebuild
with a lot of disk space available :)
-sv
On Mon, 2005-02-28 at 20:37 -0500, Jeremy Katz wrote:
On Mon, 2005-02-28 at 18:03 -0500, seth vidal wrote:
this mostly works like it should. I tested it on an fc3 system and a rawhide system with some success.
Oooh, pretty. And a step in the (right) direction of getting to a working buildsystem.
A couple of minor issues:
yum will install file deps by: yum install /path/to/file/you/need
but it won't do virtual provides in that syntax
so 'yum install foo' when foo is not a package name doesn't do anything. I compromised on this syntax by adding resolvedep. So you can do: 'yum resolvedep foo' which spits back 1 package that provides foo. Then you can pass that output to yum install and you're on your way again. That's going to require a bit more hacking I think to make it all work. There are a fair number of virtual provides in packages that make some of this not work.
I could easily add virtual provides support into 'yum install' in cvs-HEAD and this problem goes away - I'm just wondering would it make more sense to hack yum to make it comply with mach2 or to hack mach2 to make it work with yum.
-sv
On Tue, 1 Mar 2005, seth vidal wrote:
A couple of minor issues:
yum will install file deps by: yum install /path/to/file/you/need
but it won't do virtual provides in that syntax
so 'yum install foo' when foo is not a package name doesn't do anything. I compromised on this syntax by adding resolvedep. So you can do: 'yum resolvedep foo' which spits back 1 package that provides foo. Then you can pass that output to yum install and you're on your way again. That's going to require a bit more hacking I think to make it all work. There are a fair number of virtual provides in packages that make some of this not work.
Heh, oh the memories this reminds me of... Apt had/has seriously tough time trying to deal with all the virtual provides in the ways people are using it, especially as buildrequires and the build-dep operation's logic was something I never could digest really. :)
I could easily add virtual provides support into 'yum install' in cvs-HEAD and this problem goes away - I'm just wondering would it make more sense to hack yum to make it comply with mach2 or to hack mach2 to make it work with yum.
You mean "hack mach to make it work with yum" as in "import yum..." kind of thing? If so, I think that's far better approach than invoking it from through command line with all the overhead of re-re-re-reading in metadata etc - it'd not only improve speed but give far more control over things. Regardless of that, supporting virtual provides in 'yum install' would be a nice little addition to yum anyway.
- Panu -
I could easily add virtual provides support into 'yum install' in cvs-HEAD and this problem goes away - I'm just wondering would it make more sense to hack yum to make it comply with mach2 or to hack mach2 to make it work with yum.
You mean "hack mach to make it work with yum" as in "import yum..." kind of thing? If so, I think that's far better approach than invoking it from through command line with all the overhead of re-re-re-reading in metadata etc - it'd not only improve speed but give far more control over things. Regardless of that, supporting virtual provides in 'yum install' would be a nice little addition to yum anyway.
okay I added in the virtual provides to yum install options. It's just sorta hacked in right now it needs to be abstracted and cleaned up a bit, but it does what you'd expect and takes all sorts of whacked out things like:
yum install "foo > 1.1" yum install "foo == 1.1" yum install "foo = 1.1" (same as above) yum install "foo < 1.1" <=, >= are also taken.
!= is not accepted and don't make me slap anyone who asks. :)
etc etc etc.
its only an option to install atm, though, not to update, for obvious reasons
so yum 2.3.1 should work just fine with mach for what it wants to do.
-sv
Hi,
You mean "hack mach to make it work with yum" as in "import yum..." kind of thing? If so, I think that's far better approach than invoking it from through command line with all the overhead of re-re-re-reading in metadata etc - it'd not only improve speed but give far more control over things. Regardless of that, supporting virtual provides in 'yum install' would be a nice little addition to yum anyway.
There's a big conceptual problem with that approach that I still don't have a satisfying answer for.
Mach is meant to be run as user - I know way too little about security to be trusted to write perfectly safe python code. That's the biggest reason why mach-helper exists, and people tell me that this is indeed the smartest route to take. Of course it'd be easier for me as a programmer to just do everything in python. But if we did, then we'd need a good way of gaining and then dropping privileges for these operations, and I'd still feel very insecure about having written something potentially very harmful.
I've looked for other projects that have similar security issues, but haven't found any of them tackling this particular problem. Suggestions ?
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I will play you like a shark And I'll clutch at your heart I'll come flying like a spark To enflame you <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
There's a big conceptual problem with that approach that I still don't have a satisfying answer for.
Mach is meant to be run as user - I know way too little about security to be trusted to write perfectly safe python code. That's the biggest reason why mach-helper exists, and people tell me that this is indeed the smartest route to take. Of course it'd be easier for me as a programmer to just do everything in python. But if we did, then we'd need a good way of gaining and then dropping privileges for these operations, and I'd still feel very insecure about having written something potentially very harmful.
I've looked for other projects that have similar security issues, but haven't found any of them tackling this particular problem. Suggestions ?
What about the dbus suggestion? Have the client emit dbus events and have a root-running daemon listen for them to do what they wished. That way the suid root binary doesn't need to exist unless you want the daemon to not run as root.
thoughts? -sv
Am Dienstag, den 01.03.2005, 02:45 -0500 schrieb seth vidal:
On Mon, 2005-02-28 at 20:37 -0500, Jeremy Katz wrote:
On Mon, 2005-02-28 at 18:03 -0500, seth vidal wrote:
A couple of minor issues:
yum will install file deps by: yum install /path/to/file/you/need
but it won't do virtual provides in that syntax
[...]
I could easily add virtual provides support into 'yum install' in cvs-HEAD and this problem goes away - I'm just wondering would it make more sense to hack yum to make it comply with mach2 or to hack mach2 to make it work with yum.
IMHO it should be done in yum. I often ran into this problem already during normal yum usage (e.g. built tests outside a build system / directly from CVS). Typing $ yum install XFree86-devel is easier and a lot faster faster then $ yum provides XFree86-devel <filter result> $ yum install xorg-x11-devel
CU thl
I could easily add virtual provides support into 'yum install' in cvs-HEAD and this problem goes away - I'm just wondering would it make more sense to hack yum to make it comply with mach2 or to hack mach2 to make it work with yum.
IMHO it should be done in yum. I often ran into this problem already during normal yum usage (e.g. built tests outside a build system / directly from CVS). Typing $ yum install XFree86-devel is easier and a lot faster faster then $ yum provides XFree86-devel
<filter result> $ yum install xorg-x11-devel
you could have done this all along, though, with resolvedep. However, it's been implemented. The major reason I don't like it in 'install' is that it further complicates the things a user could put there, it's just more code to sift through when someone breaks something.
-sv
buildsys@lists.fedoraproject.org
-
Jeremy Katz -
Panu Matilainen -
seth vidal -
Thomas Vander Stichele -
Thorsten Leemhuis