Difference between revisions of "Package management"

From GNUstepWiki
Jump to navigation Jump to search
(Package management requirements and proposed solutions)
m (Current implementation)
 
(3 intermediate revisions by 3 users not shown)
Line 33: Line 33:
 
* should a multi-platform format be server-side strippable to decrease download size? (this could be hard, might be easier to develop strip tools instead)
 
* should a multi-platform format be server-side strippable to decrease download size? (this could be hard, might be easier to develop strip tools instead)
  
== Proposed solutions ==
+
== Current implementations ==
  
[[GNUstep and HPMS HowTO]]
+
There is an implementation called (surprise!) Installer.app http://www.etoile-project.org/etoile/mediawiki/index.php?title=Installer in Etoile.

Latest revision as of 18:11, 13 September 2006

Package management tools will be required on GNUstep-only platforms, and are nice-to-have on platforms where GNUstep is only one environment. Having working package management tools makes the environment much more accessable to end users and application developers, by lowering the threshold to having a running environment.

Please add points below as you think of them, it's useful to collect issues and questions in one place.

Scope for package management within GNUstep

Package management tools will need to address some of the following issues:

  • how do we ensure the authenticity and integrity of a package?
  • how many competing package formats do we really need?
  • should a package management tool interact with a (native) package management environment? (ie create synthetic dpkg data on install so that platform package management can be used by the system manager?)
  • internationalisation of packages - making sure that installation metadata is separated from end-user information

Source packaging

  • is FTP'ing the existing tar.gz or CVS approach right? (ie no package management?)

Binary packaging

We need to make sure that users installing binary packages don't get unpleasant surprises:

  • how can installers inform end-users before install if the package is not suitable for their platform? (need to get some agreement on metadata)
  • how can installers maximise user flexibility in terms of application or framework installation, especially as we can't necessarily control filesystem layout?

Multi-platform packages make sense for some application providers, especially if we can get cross-building working in Project Center.

  • should non-flat packages be generated automatically by package creation tools integrated with GNUstep make? (we'd need merge and strip tools at the least)
  • should a multi-platform format be server-side strippable to decrease download size? (this could be hard, might be easier to develop strip tools instead)

Current implementations

There is an implementation called (surprise!) Installer.app http://www.etoile-project.org/etoile/mediawiki/index.php?title=Installer in Etoile.