From Fedora Project Wiki

< FWN‎ | Beats

m (Changed references to new style.)
Line 14: Line 14:
In order to support truly portable packages, it is necessary to standardize not only the package format, but the available libraries, library versions, file locations, utility commands, and system services. This is proved by the fact that, for example, Fedora and SUSE RPMs do not usually cleanly install on other distribution, despite using a common package format.
In order to support truly portable packages, it is necessary to standardize not only the package format, but the available libraries, library versions, file locations, utility commands, and system services. This is proved by the fact that, for example, Fedora and SUSE RPMs do not usually cleanly install on other distribution, despite using a common package format.


The Linux Standard Base (LSB)[0] project of The Linux Foundation[1] has been working on such a system-wide standard for many years, walking the fine line between standardizing too little (yielding an ineffective standard) and standardizing too much (leaving little room for differentiation between distributions). The work of LSB has been internationally recognized as ISO/IEC 23360, and Fedora conforms to the LSB.
The Linux Standard Base (LSB)<ref>http://www.linuxfoundation.org/en/LSB
</ref> project of The Linux Foundation<ref>http://www.linuxfoundation.org/</ref>
has been working on such a system-wide standard for many years, walking the fine line between standardizing too little (yielding an ineffective standard) and standardizing too much (leaving little room for differentiation between distributions). The work of LSB has been internationally recognized as ISO/IEC 23360, and Fedora conforms to the LSB.


In terms of packaging, LSB mandates support for a restricted version of RPM[2], without triggers and with restrictions on the content and execution-order requirements of scriptlets[3]. These restrictions ensure that LSB-compliant RPMs can be successfully processed by conversion tools such as Debian's "alien" command. However, as its name implies, the LSB defines only a base for a distribution, and many of a distribution's packages need to take advantage of a broader feature set than provided for by the LSB. This need is expressed in the more advanced features provided by the full RPM and DEB package specifications.
In terms of packaging, LSB mandates support for a restricted version of RPM<ref>http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/packagefmt.html</ref>, without triggers and with restrictions on the content and execution-order requirements of scriptlets<ref>http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/pkgscripts.html</ref>. These restrictions ensure that LSB-compliant RPMs can be successfully processed by conversion tools such as Debian's "alien" command. However, as its name implies, the LSB defines only a base for a distribution, and many of a distribution's packages need to take advantage of a broader feature set than provided for by the LSB. This need is expressed in the more advanced features provided by the full RPM and DEB package specifications.


It should be noted that a number of package systems have been developed which attempt to address cross-distribution packaging issues, including Autopackage[4], ZeroInstall[5], and Klik[6] (ZeroInstall and Klik also enabling user-level package installation) -- but these have not gain widespread support.
It should be noted that a number of package systems have been developed which attempt to address cross-distribution packaging issues, including Autopackage<ref>http://autopackage.org/</ref>, ZeroInstall<ref>http://zero-install.sourceforge.net/</ref>, and Klik<ref>http://klik.atekon.de/</ref> (ZeroInstall and Klik also enabling user-level package installation) -- but these have not gain widespread support.


The second advantage to a standard package format is a reduction in the duplication of labour by each distribution, especially if packaging information (such as a basic RPM .spec file) is provided by the upstream software source. However, packaging standards, security configuration (such as SELinux policy), and naming conventions vary so significantly between distributions that extensive customization of the package is usually required, greatly reducing the value of distributing standard package information.
The second advantage to a standard package format is a reduction in the duplication of labour by each distribution, especially if packaging information (such as a basic RPM .spec file) is provided by the upstream software source. However, packaging standards, security configuration (such as SELinux policy), and naming conventions vary so significantly between distributions that extensive customization of the package is usually required, greatly reducing the value of distributing standard package information.
Line 24: Line 26:
The existence of multiple linux distributions fuels a productive competitiveness which spurs innovation. As long as multiple distributions thrive, multiple package formats are likely to remain in use.
The existence of multiple linux distributions fuels a productive competitiveness which spurs innovation. As long as multiple distributions thrive, multiple package formats are likely to remain in use.


--
<references/>
 
[0] http://www.linuxfoundation.org/en/LSB
 
[1] http://www.linuxfoundation.org/
 
[2]http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/packagefmt.html
 
[3]  http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/pkgscripts.html
 
[4] http://autopackage.org/
 
[5] http://zero-install.sourceforge.net/
 
[6] http://klik.atekon.de/

Revision as of 03:20, 9 February 2009

Ask Fedora

In this section, we answer general questions from Fedora community. Send your questions to askfedora AT fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published.

http://fedoraproject.org/wiki/AskFedora

Standardized Package Format

Arthur Pemberton asked: "When are the big players in the Linux ecosystem going to converge on a single package system which is a superset of .deb and .rpm? This seems like something that needs to be done before this mostly unnecessary difference gets too ingrained to be changed."

Two reasons are usually given for converging on a single packaging standard. The first is to create packages that can be installed on many distributions without change; this is particularly attractive to third-party software vendors who wish to create a single repository of their software for use with a range of distributions rather than package and distribute their software within those distributions.

In order to support truly portable packages, it is necessary to standardize not only the package format, but the available libraries, library versions, file locations, utility commands, and system services. This is proved by the fact that, for example, Fedora and SUSE RPMs do not usually cleanly install on other distribution, despite using a common package format.

The Linux Standard Base (LSB)[1] project of The Linux Foundation[2]

has been working on such a system-wide standard for many years, walking the fine line between standardizing too little (yielding an ineffective standard) and standardizing too much (leaving little room for differentiation between distributions). The work of LSB has been internationally recognized as ISO/IEC 23360, and Fedora conforms to the LSB.

In terms of packaging, LSB mandates support for a restricted version of RPM[3], without triggers and with restrictions on the content and execution-order requirements of scriptlets[4]. These restrictions ensure that LSB-compliant RPMs can be successfully processed by conversion tools such as Debian's "alien" command. However, as its name implies, the LSB defines only a base for a distribution, and many of a distribution's packages need to take advantage of a broader feature set than provided for by the LSB. This need is expressed in the more advanced features provided by the full RPM and DEB package specifications.

It should be noted that a number of package systems have been developed which attempt to address cross-distribution packaging issues, including Autopackage[5], ZeroInstall[6], and Klik[7] (ZeroInstall and Klik also enabling user-level package installation) -- but these have not gain widespread support.

The second advantage to a standard package format is a reduction in the duplication of labour by each distribution, especially if packaging information (such as a basic RPM .spec file) is provided by the upstream software source. However, packaging standards, security configuration (such as SELinux policy), and naming conventions vary so significantly between distributions that extensive customization of the package is usually required, greatly reducing the value of distributing standard package information.

The existence of multiple linux distributions fuels a productive competitiveness which spurs innovation. As long as multiple distributions thrive, multiple package formats are likely to remain in use.