[Rpm-maint] selective/minimal package installation using rpm

[Mr Dash Four]

Apologies if this is the wrong mailing list, but I could not find more 
appropriate place to post this in...

In my line of work I often need to use cross compilation and rpm 
build-up of packages. Typical scenario would be to use x86_64-based 
machine to compile and build i686-based rpm packages.

Very often, as part of that process, I have to 'selectively' install 
corresponding i686 packages (plus their -devel counterparts) to satisfy 
the target (i.e. i686-based) dependencies. By 'selectively' I mean to 
install, more often than not, just the library objects (.so files) 
located in /lib or /usr/lib directories with the odd exception of 
including files from /usr/include directories (which, most often that 
not are the same as the x86_64 version with the odd addition of *-32.h 
for 32bit and *-64.h for the 64bit architectures).

This brings an additional headaches as I have to keep a separate file 
list to track what has been installed and basically maintain it 
manually.And this is where I find rpm could be of help to me as its 
abilities are somewhat limited at present.

Currently rpm does not allow me to have a fine-grained control on what 
to install and it offers me either complete installation or (possible) 
relocation of the target package paths. I write 'possible' because that 
is, more often than not, NOT possible and rpm plainly refuses to install 
a package if I do relocate the target path.

Ideally, I would like to have an option to ask rpm to install a 
'minimalistic' version of the package and maintain it. Here is one example:

Lets suppose that to satisfy one of the target package dependencies I 
have to part-install curl-devel.i686. In other words I just need the 
following files (bearing in mind that the host machine on which this 
package will be build is x86_64):

/usr/include/curl
*/usr/include/curl/curl.h
/usr/include/curl/curlbuild-32.h
*/usr/include/curl/curlbuild.h
*/usr/include/curl/curlrules.h
*/usr/include/curl/curlver.h
*/usr/include/curl/easy.h
*/usr/include/curl/mprintf.h
*/usr/include/curl/multi.h
*/usr/include/curl/stdcheaders.h
*/usr/include/curl/typecheck-gcc.h
*/usr/include/curl/types.h
/usr/lib/libcurl.so
/usr/lib/pkgconfig/libcurl.pc

Files marked with '*' are the same as the host machine (x86_64) and 
probably already exist there. As it stands, if I try "yum install 
curl-devel.i686" I will be asked to also install the following 
additional packages on my x86_64 system:

Installing:
libcurl-devel.i686

Installing for dependencies:
cyrus-sasl-lib.i686
krb5-libs.i686
libcurl.i686
libidn.i686
libselinux.i686
libssh2.i686
ncurses-libs.i686
nss.i686
nss-softokn.i686
openldap.i686
openssl.i686

This has also a snowball effect if the package I want to install is 
something else, which is more complex. A real nightmare! In actual fact, 
for installing the specific files from this package (as I have indicated 
above) the following is NOT needed:

readline.i686
sqlite.i686
db4.i686

If I go ahead and install all of the above packages as suggested by 
rpm/yum then my existing x86_64 binary executables will most definitely 
be overwritten, not to mention that if I have existing configuration for 
the corresponding x86_64 packages that will be wiped out as well - that 
is very BAD news indeed!

This is just a simple example, but I think the point is clear: If I have 
the ability to use 'selective'/'minimalistic' installation using rpm I 
won't need to keep a separate list/track of what I have extracted and 
installed manually from the i686 packages. Most important of all, I 
won't need to spend hours executing ldd to track dependencies on what I 
have to install (and I am human after all and prone to making mistakes!).

So, the question which is the very reason for starting this thread - is 
this feasible and possible to be implemented in rpm in, hopefully, the 
near future?

It will be of great help to developers like me and, as I wrote above, I 
won't need to spend extra hours on a) installing the 'right' 
dependencies and b) maintaining all that stuff. thanks a lot in advance!