On Jul 12, 2009, at 6:34 PM, Michael Lasevich wrote:
> Jeff Johnson wrote:
>> On Jul 10, 2009, at 7:07 PM, Michael Lasevich wrote:
>>> Weirdly enough double quotes do work, but ONLY on files with
>>> spaces in it. Any other file in double quotes causes an error and
>>> as I was generating the spec file list from a script, I ended up
>>> putting extra code to quote only files with spaces in them. Some
>>> odd parsing that is, but as long as I know what it is, it works.
>> Hmm, odd that quotes don't work for all file paths ... checking ...
>> worksforme. So there's some other factor than quoted paths.
> I will come up with some examples and post the results. Again, this
> may be something that was fixed in rpm5 so I could be wasting your
> time. I will post what I find.
AFAIK all rpm behavior wrto spaces within paths is identical for years.
But if you post a spec file with a reproducer I'll sort the issue for
>>> Now, if only I can find a way to add a default relocation mapping
>>> for installation into rpmmacros file, things would be perfect -
>>> but thats a whole other problem.
>> What's this issue? I'm not sure what "default relocation mapping"
> Ok, this is a completely separate issue. Here is the background -
> I've been using rpm as non-root user for a project for a while.
> Basically this gives me ability to harness all the awesome power of
> rpm to do cross-platform package level control of components on an
> application running as a non-privileged user as long as the platform
> has some sort of a stock installation of rpm (there is one for
> almost every platform!!). Works great (except for a long standing
> bug in some versions of 4.x that had lock file pathname hardcoded,
> but that was easily enough fixed via locl file directory permissions
> and I am pretty sure its been fixed in rpm code long ago) . The only
> catch was that I needed to compile my rpms with a prefix (easy
> enough) and use a wrapper on rpm to do "rpm --prefix MYPATH" to any
> rpm command (plus some rpmmacros to point to proper db). Anyway, I
> have long wanted to add yum to the mix for updating. I messed with
> it a bit and got it to work as non-root as well ( mostly path fixes
> and removal of root-only safety check) but then I run into a wall.
> YUM uses rpm python bindings to do installations and not command
> line, so it is not using my rpm wrapper and not passing relocation
> information to rpm. I tried to find a way to pass relocation
> information via python API - but I can't seem to find a way to do
> so. The only hope I am holding out is that there is a way to add a
> "default" relocation information via macros file (or via
> rpm.addMacro() API call) so that rpm assumes this relocation
> information if no parameters are passed via rpm executable or via
> API install. The only thing I found was _prefix macro, but that is I
> believe for package building, not for installation. And just for
> the sake of completeness, I want to mention that I cannot use the
> obvious "--root" (which would make life 1000 times easier) because
> it uses chroot and you need to be root to do so. So I know it is a
> long shot, but if there is any idea as to how to get around this - I
> am all ears.
OK. There's two approaches, hacking in python is easiest, but a macro
to carry persistent relocations can done if absolutely necessary.
The easy hack is to populate your relocations in the last arg
of rpmtsAddInstallElement(), passed to python/rpmts-py.c through
yum directly. All that's needed is to convert a python tuple
of [ "/old", "/new" ] relocations into a rpmRelocation array.
The more subtle hack is to do the same with macro expansions.
All that is hard with macros instead of python tuples is that
macros are strings, so one has to parse out boundaries and
invent syntax, etc etc. The code to parse dependency whiteout
into an array of pairs in lib/depends.c can be modified to
do what you want.
But changing rpm-python with a keyword arument to add relocations,
and then figgering a way to pass the keyword arg in yum, is likely
much more maintainable.
If none of the above makes sense, holler, and I'll whack out a patch.
Alas, neither implementation can be put into RPM because of
and interoperability issues.
73 de Jeff
Received on Mon Jul 13 01:08:57 2009