Universal package specification

[Eugene Gorodinsky]

2009/11/28 martin f krafft <madduck at madduck.net>:
> also sprach Eugene Gorodinsky <e.gorodinsky at gmail.com> [2009.11.28.1123 +0100]:
>> 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.
>
> To carry through with what you propose, you would need full support
> from Debian, RedHat/Fedora, and probably Novell/OpenSuse. If the LSB
> efforts are any measure (taking so long to specify standards that
> they are readily superseeded before completion, e.g. sysv init vs.
> event-based like upstart), then your chances are very slim.
>
Nevertheless it's worth a try.

> Don't get me wrong, you have a noble goal, but if my experience with
> vcs-pkg.org is any indication, then the aforementioned large distros
> don't care.
>
> Why should Debian, RedHat/Fedora, and probably Novell/OpenSuse
> abandon their package formats and converge on a universal one?
>
In the long run less resources will need to be wasted on package
maintenance and more can be directed at other things.

> How do you think you will address fundamental differences, like
> single .spec files vs. the ./debian/ directory?
>
AFAIK this applies to source packages and not to binary ones.

> We would have to standardise names and version schematar— how?
>
Only for shared libraries and dbus interfaces. And I believe those are
already the same at least in debian and redhat systems.

>> 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.
>
> This is where you'll need proper symbol versioning done right. How
> do you want to get all the required knowledge for that out to the
> people?
>
By proper symbol versioning do you mean shared libraries (and their
versions) or something else?

>> 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.
>
> I would be surprised if Debian were to embrace file dependencies.
>
Why is that surprising?

> Ben Finney said, and you replied:
>> > 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.
>
> All the data are maintained in a single location. They are then
> cached in multiple locations. That's not duplication, IMHO.
>
Maintained - yes. But I meant the actual distribution