DebForMeeGo

(Alternative Solution)
(Why keep deb)
Line 17: Line 17:
* will be the first packaging system to allow multiarch.
* will be the first packaging system to allow multiarch.
* seems to be already tested in multi-arch (even optimized versions per arch using multiple architectures), while RPM seems to be immature in that area (RPM expert's comment needed)
* seems to be already tested in multi-arch (even optimized versions per arch using multiple architectures), while RPM seems to be immature in that area (RPM expert's comment needed)
 +
* tools for verifying (e.g. lintian) available
== Why switch to rpm ==
== Why switch to rpm ==

Revision as of 15:19, 17 February 2010

This page collects all arguments for and against keeping the *.deb package format in MeeGo.

Contents

Scope

the aim is at least to keep the *.deb package format in the MeeGo distributions aiming at Nokia Phones/ Handhelds. Although using the .deb format throughout the MeeGo project is desireable, not arguments here apply to the same extend looking at the whole project.

Why keep deb

  • No porting for Maemo packages needed
  • Maemo has the bigger community
  • community infrastructure is based on deb - would be thrown away
  • deb has wider adoption (Ubuntu, Google Chrome OS, Debian)
  • allows syncing from Debian/ Ubuntu
  • is used for distributions targetting end users
    • packages contain lots of related fixes
  • not to throw away experience gained with maemo which is reflected in the packaging
  • deb package can contain license information into the XBS-License field of the control file.
  • will be the first packaging system to allow multiarch.
  • seems to be already tested in multi-arch (even optimized versions per arch using multiple architectures), while RPM seems to be immature in that area (RPM expert's comment needed)
  • tools for verifying (e.g. lintian) available

Why switch to rpm

  • No porting for Moblin packages needed
  • Moblin build infrastructure has more capabilities already in place, such as imaging.

Alternative Solution

  • Keep a Debian base system, and provide third-party applications in an LSB package formet (which is RPM inside). LSB-compliant RPM should install flawlessly, and that way the frontier between system packages (DEB) and third-party applications (RPM) is well defined.
  • Add the imaging feature to the Deb package.