Bug 6430 - [spec] packaging dependencies of applications
: [spec] packaging dependencies of applications
: NEW
: Moblin Compliance Tools
Moblin Compliance Specification
: unspecified
: Netbook Moblin Linux
: Undecided normal
: ---
:
:
:
:
 
 
Reported: 2009-09-24 18:26 PST by
Modified: 2009-09-25 06:33 PST (History)


Attachments




Description From 2009-09-24 18:26:25 PST
The specification should define requirements to packaging dependencies of
applications. 

Just to remind what the problem is. Distributions implement different package
name schemes, so approach used for applications coming from distribution
vendors does not fit ISVs well. A list of packages, that provides required
pieces of the platform, will be different on different distributions.

There are at least several solutions.

1. To require unified package names across all Moblin compliant distributions.

2. The LSB way. Each application has a single dependency moblin (>= 2.0). At
the same time all OSVs provides metapackage "moblin" that covers all
functionality described in the Moblin specification. 

3. A possible variation of the previous approach is to have the single moblin
dependency separated to several ones (e.g. moblin-core, moblin-foundations,
moblin-connectivity, etc.). Granulary can vary greatly, starting from several
large modules up to unified aliasing almost all distribution packages.

4. Empty list of dependencies at all.

5. Implementation of new tools for automatic translation dependencies from some
unified list to distribution specific ones.

6. Per distribution application packages.


My comments on the approaches.

1. Unlikely to happen.

2,3,5. Implementation of these approaches seems to be problematic in Moblin 2.0
timeframe. May be good for future releases.

4. May be good for Moblin 2.0 timeframe, especially if all components of Moblin
2.0 specification are installed by default. 
Checks for required pieces can be implemented in preinstall scripts as well.

6. May be the best way for end-users (if choice is hidden by some automation)
since it enables fine-grained autoinstallation of all required pieces from
repositories. But this approach is a headache for ISVs. The latter issue can be
mitigated by tools for automatic generation appropriate packages for all
Moblin-compliant distributions from a single source (for example, from rpm for
the Moblin Reference Implementation).
------- Comment #1 From 2009-09-25 06:33:49 PST -------
Thanks for filing this.  There's another issue as well, which is not just
describing the dependencies, but also their versions.  If left alone,
rpmbuild's find-provides functionality will happily build in quite specific
version dependencies, which means that as Moblin moves on, it will become very
difficult to build packages which work on older Moblin distros even if they
should work: often the specific version of a library package will get inserted
as part of a dependency, making it incompatible at install time with a system
with an earlier version that might be run-time compatible.  LSB solves this by
means of a special SDK which forces what we want; there's a Moblin SDK underway
but it will have quite different aims and I'm unsure if we'll be able to get,
or want, the equivalent of the LSB one.