RPMs and *.desktop files

[Mike A. Harris]

On Wed, 3 Mar 2004, Thomas Vander Stichele wrote:

>> >^^^ It might not be a good idea to make rpm packages that try to work on
>> >multiple distros.  YMMV.
>> >  
>> >
>> I'm a little surprised by this. I thought one of the goals of these 
>> standards was to help making Linux distros and desktop environments more 
>> compatible with each other.
>
>Due to each distribution having their own naming standards, their own
>set of packages, different actual .so.x libraries in the packages, and
>so on, it is really hard to make rpms that work on lots of distros,
>especially when the software has less than the most trivial of
>dependencies, or needs some sort of desktop/distro integration.
>
>When you do succeed, you probably used so many hacks/workarounds and the
>package will be worse than a package made for the actual distribution. 
>So in general, my opinion is to just not try doing this.  Personally, I
>very seldomly install packages that are for a different version of my
>distro, even...
>
>If you want to experience it firsthand, how about this.  Try building a
>system with 1/3 mdk packages, 1/3 suse packages and 1/3 fedora packages.
>
>Anyway, as I said, my two cents - I'm sure other people believe that it
>is still possible to package cross-distro.

Different distributions often have different goals, and different
feature sets, sometimes which may conflict with each other.  
Additionally different distributions may have customer/user
requests/preferences that differ greatly.  There are many other
various technical reasons for different distributions to do 
things their own way.

Just think how much work would ever actually get done, if every 
single packaging decision, feature inclusion decision, etc. had 
to be negotiated between Red Hat, Mandrake, SuSE, Conectiva, and 
every other rpm based distribution until everyone simultaneously 
agreed upon one thing.

The answer is "not much".  Each distribution has it's own release 
schedules and goals, some overlapping, some not.  I'm not going 
to try and convince SuSE to create a XFree86-libs-data subpackage 
just because we have one (I assume they do not, but for all I 
know maybe they do, who knows).  That subpackage was created for 
a technical reason, which solved a real world problem for me in 
the Red Hat OS distribution.  Other vendors may or may not 
experience that problem and may or may not agree with the 
solution.  Perhaps someone else decides to fix the problem I 
fixed that way by doing it some other way.  Perhaps another 
distribution doesn't see the issue as a problem at all and would 
just ship things as they were before.

This really has nothing to do with "standards".  You standardize 
things not only where there is a gain from standardization, but 
where there is a LARGE enough gain from standardizing and 
cooperating on a particular issue that OUTWEIGHS the COSTS 
INVOLVED in doing that particular level of standardization.

To be quite honest, I see absolutely zero value to Red Hat to 
package X in rpm format in a way that cleanly installs in a 
compatible way on Mandrake or SuSE or Foobedoo Linux any more 
than I would see Suse, Mandrake or Foobeedoo Linux finding real 
world value making their X packaging cleanly install on Red Hat 
OS products.

My main point is that, none of us distribution vendors are too 
interested in wasting our finite limited engineering resources on 
solving problems that are minor to the point they do not matter 
at all, compared to the much much larger problems that really do 
exist and are definitely worth throwing engineering resources at.

By all means, if some volunteer packager in the community feels 
the need to have one single set of X rpm packages that cleanly 
install and work on Red Hat OS's, SuSE OS's, Mandrake, Conectiva, 
PLD, and other RPM based distributions, and if that person goes 
through all the trouble to make this set of rpm packages properly 
and cleanly integrate with every single rpm based OS out there, 
they are more than welcome to try to do so.

The best they will be able to do is to make something that tries 
to be all things to all people, and ends up being not-quite-there 
for anyone, as it would be next to impossible to package 
something like X in a way that integrates properly in all OS's 
out there.

This isn't something that any RPM based OS vendor or volunteer 
project is really going to find any value spending resources on.  

While some end users might find value in it, they're free to try 
their hand at implementing it however, and I wish them lots of 
luck.