Why can't RPM spec files be coverted to ebuilds

In evaluating converting the jpackage spec repository to ebuilds in an automated way I came across the following obstacles

    1) SourceNN: variables don't frequently contain a valid URL
    2) sub %packages
        # ebuilds have one inherit strength in that they typically map one tarball and one package per ebuild.  With this you are maintaining one source package per binary package.  To add or remove features USE flags were invented.  Since most end users are not compiling from source binary distributions invented ways to sub divide the packaged files into multiple binary packages.  The only benefit to this division of packages is saving bandwidth and space.

    3) Dependencies are loosely coupled and not globally tracked.
    4) ebuilds are uniquely mapped category + package and specs are just mapped by package.
        #Using the existing Group: would be possible, but more complicated than just adding a Category: variable

With this comes a couple questions...

1) How many Windows, Sun or IBM software packages come with separate package just for the docs?  (Yes some packages allow you not to install docs on the initial install)

2) When your XP updates are you asked if you want the docs and demo to go with it? No, you see a progress bar and just wait.  So there are two sides to this bandwidth and disk space question. 

    Remote server
    End user

I don't think most open source projects remote server is hitting a bottleneck for disk space or bandwidth.  Most successful projects are effectively using various forms of server and geo load balancing to distribute and localize.

So then comes the more questions...

3) Who is the end user and how do we invest our time so that they have the most efficient packaging as possible.

There are hundreds of thousands of software packages, but only a handful of package formats.  (RPM, dpkg, xpkg.. etc)  In my evaluation for which binary package to choose for OSUNIX I came across some very interesting numbers.  *If* distributions really wanted to save space and bandwidth they'd quit using gzip and bzip2.  lzma and xz (lzma2) showed in my early tests to significantly save space and were faster to extract.   Using xar for our oxe packages we won on size and speed vs dpkg and rpm even though xar compresses per file.

4) How often do people install the docs?

You may wonder why I care, but this is about saving time and giving the greatest benefit to the developers and end users.  There's 649 packages I wanted to use from the jpackage repo.  Roughly 2145 of the sub packages were either javadoc, manual or demo related.  How and why were the other packages being divided up?  ebuild package maintainers may have a lot of bad habits, but it's clear that there's no panacea to packaging.  It all goes back to having stronger policies in place that are based on logic and actually solving problems. </rant>