Universal package specification

[Eugene Gorodinsky]

2009/11/28 Ben Finney <ben+freedesktop at benfinney.id.au>:
> Eugene Gorodinsky <e.gorodinsky at gmail.com> writes:
>
>> I believe one of the main problems on Linux is the lack of a universal
>> package format that works on all major distributions.
>
> Could you clarify why this is a problem, and for whom? I'm sure we could
> all imagine reasons, but it would be good to be explicit about what
> problem is being solved here.
>
Some packages are available in rpm only, others are available in dpkg
only. Some packages are available in rpm and in dpkg, but not in the
formats for other distributions. If those distributions start
supporting either rpm or dpkg they will need to make sure they are
fully compatible with debian or redhat, because you don't really know
what it is that a package depends on: is it some particular files
(e.g. config files) or is it the shared libraries provided or maybe it
needs a certain dbus interface etc. Two packages depending on a third
package may depend on different interfaces, thus it's not possible to
replace this third package with a compatible one without closely
studying what it is that all of the packages that have it in their
dependencies really depend on. A more fine grained dependency
mechanism would allow that.


>> Existing package formats were developed for specific distributions and
>> don't offer the features required by software that is not
>> distribution-specific. However most software isn't really distribution
>> specific.
>
> Perhaps not, but the requirements for getting that software installed
> and working on a particular distribution *is* specific to the packaging
> system used on that distribution.
>
My experience is limited, but usually having specific libraries on the
system is enough to get software to work. This could partially be
because of the FHS conforming filesystems and other plumbing parts
being similar. The software that depends on the filesystem in such a
way should probably be rewritten to use a shared library of some sort
- tying software to parts of the filesystem is really a bad idea (e.g.
if it weren't for the software that was written to use open sound
system directly, OSS would have probably been dropped a long time
ago).

Could you give an example to illustrate the problem?


>That's a big part of the problem
> addressed by a packaging system (note: the whole system, not just the
> format of package data).
The format by itself is useless without the package system supporting
the features it provides, obviously. But the package system is
powerless if the package format does not provide some necessary
information to it. So the package format shouldn't be considered
separately, but rather as part of the package management solution.


>> A lot of times the only difference between software packaged for one
>> distribution and the same software packaged for another distribution
>> is the directories this software is installed into.
>
> I don't find this to be a fair representation. Rather, software packaged
> for different packaging systems contains very different *instructions*
> to the packaging systems, even if the software work ends up in similar
> filesystem locations. The filesystem locations are one — important but
> not dominant — aspect of the information in a package.
>
By instructions, do you mean scripting, or something else? If it is
scripting, then yes, I agree. My opinion on this right now is that the
package system should provide some limited scripting capabilities,
although I must confess, I haven't researched this thoroughly.


>> Also since packages are not only distributed by themselves, but (and
>> this happens more and more often) through repositories, some of the
>> header data in packages such as rpm or dpkg packages is duplicated.
>
> What does this mean? Can you give an example of “header data” that is
> duplicated, and where this duplication occurs?
>
The control file in dpkg and apt Packages file for example.