RPMs and *.desktop files
Mike A. Harris
mharris at www.linux.org.uk
Wed Mar 3 11:43:55 EET 2004
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
>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
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
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
More information about the xdg