Universal package specification (the long way to go...)

[Eugene Gorodinsky]

Sorry, forgotten to cc this to the list.


---------- Forwarded message ----------
From: Eugene Gorodinsky <e.gorodinsky at gmail.com>
Date: 2009/12/2
Subject: Re: Universal package specification (the long way to go...)
To: Stanislav Brabec <sbrabec at suse.cz>


2009/11/30 Stanislav Brabec <sbrabec at suse.cz>:
> Eugene Gorodinsky wrote:
>> Hi Stanislav.
>>
>> This isn't a spec file format that I'm trying to introduce. This is a
>> specification of a universal package format. Something like dpkg or
>> rpm, but for packages not specific to a certain distribution.
>
> Do you only have ambitions to create a format for third party binary
> packages that fit to all distributions without creating build
> description?
>
Yes, right now this is what concerns me. Because of the open source
nature of Linux the problem is less apparent since you can freely
modify a piece of software to work with your distribution. A more
efficient aproach would be to build upon a standard platform. LSB is
such a platform but it puts a lot of restrictions on what the system
should be, when in reality the only thing that needs to be
standardised are the shared libraries. Or, to be more precise, all of
the API that needs to be standardised can be put into the shared
libraries.

> Then you have to fulfill following requirements:
>
> - Dependencies: Different package requirements in different distros
> (described in the last mail).
>
That is why I'm proposing a standard based on shared libraries (and
dbus interfaces, but those are less important so for simplicity's sake
I'm trying to ignore it for now)

> - Package repositories: Packages must support maintenance update process
> (advisories, security classification), forming repositories of packages,
> signing contents of these repositories, creating verified date stamps.
> Differential updates of large packages would be very welcome.
>
The signing - I've already put into the specification. As for
classification of updates and differential updates - I will think on
how this could be done, thank you.

> - Binary compatibility: There is only a limited binary compatibility
> between distributions. Everything above the LSB specification may
> require different binaries for different distributions or bundling
> custom libraries together with the project. Do you want to limit your
> specification for LSB compatible stuff or do you plan to provide distro
> specific binaries?
>
No, IMHO distro-specific binaries should be provided in
distro-specific packages. The standard should simply state which
libraries are to be provided by distributions and what the functions
in them should do.

> - Architectures: Solve different architectures best. There may be
> architecture independent parts, that should be common. Downloaded files
> should not be extremely large for packages that support >10
> architectures.
>
I have that in my specification already, I think. A package is
delivered as several files, one being the package manifest, the others
simply containers for files. The manifest specifies which of the
containers should be used with what arch.

> - Languages: Support for language pack on the level that distro
> packaging system already supports. (Often done via virtual symbols or
> specially named packages.)
>
This should be possible to do with optional components and component
groups that are already supported by the package format.

> - Versioning: Different distros have different rules for defining
> versions (e. g. all-distro-wide compare of versions 1.4rc1 and 1.4 is
> undefined). Different distros different methods to ensure incremental
> versions scheme: Epoch, version prefix.
>
Since this is a cross-distro package, I'm not sure this applies.

> - Virtual symbols: Provide correct virtual symbols and virtual
> requirements in distros that support it.
>
This is actually done with interface types for this format.

> - Sub-packages: Define support for partial installation (e. g.
> sub-packages). Distros may require separate packaging shared libraries
> and special names of these packages.
>
Already have that :)
Have a look at the package manifest specification, if you're
interested. A package can contain components.

> - Integration: Such packages would require seamless support with in
> existing end-user tools. Writing of connection code e. g. for DPKG, YUM,
> URPMI, ZYPP would be required for adoption.
>
Yes, this will probably be done at some point in the future.

> --
> Best Regards / S pozdravem,
>
> Stanislav Brabec
> software developer
> ---------------------------------------------------------------------
> SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
> Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
> 190 00 Praha 9                                  fax: +420 284 028 951
> Czech Republic                                    http://www.suse.cz/
>
>