An attempt at improving cross-distribution software deployment: The Psys Library

[Eugene Gorodinsky]

The bigest problem of distributing software in an executable is the
security risks. For example you can't test if the package has been
tampered with or not. IMHO it's much better to spend the time
developing a common package format specifically designed for
third-party packages. But that effort probably requires all the
distributions to have the same package naming conventions.

2010/6/23 Denis Washington <dwashington at gmx.net>:
> Hi,
>
> Cross-distribution software deployment on Linux remains to be a big problem.
> Basically, an independent software provider (ISV) has two choices:
>
> - Creating separate packages for every distribution (or, at least, every
> package format). This provides a high level of integration with the
> distribution, but is a relatively high investment for an ISV, which must not
> understand only one, but multiple packaging systems. Also, this approach
> doesn't help users of smaller distributions with less-mainstream packaging
> systems, for which most probably no packages will be built.
>
> - Bypassing the package manager completely by deploying an executable
> installer which essentially just copies files. This has the obvious
> advantage of really working on any distribution, and also lowers the level
> of investment required by the ISV remarkably (especially if the software is
> deployed with a cross-platform installer framework, which requires the ISV
> to develop only one solution for all supported operating systems). But the
> equally obvious disadvantage is the complete lack of integration; the
> package manager has no control over the installation and cannot avoid
> conflicts with other packages, and users cannot manage (e.g. uninstall) the
> software with their distribution's software management tools.
>
> As can be seen quickly, both solutions are far from optimal.
>
> In 2006, the Free Standards Group (the organisation behind the LSB, whose
> CTO was Debian founder Ian Murdock at that time) attempted to do better. In
> an LSB face-to-face meeting in Berlin, attended by several representatives
> of major distributions (including Red Hat, Novell, Mandriva and Ubuntu) and
> ISVs, the topic was discussed. The approach promoted by Murdock, and
> generally agreed upon by the attendants, was to bridge the gap between
> executable installers and package managers with a simple LSB-standardized
> programming interface - later codenamed the "Berlin Packaging API". The idea
> was to enable installer programs to tell the package manager when they
> install or uninstall software, giving the package manager the opportunity to
> update its package database accordingly [1]. Unfortunately, this idea didn't
> seem to be followed by any kind of standards process or implementation
> effort, and so the project eventually died.
>
> Today, I am pleased to announce a project to you which tries to reignite the
> Berlin Packaging API effort with a concrete design and a proof-of-concept
> implementation ready for testing: the "Psys Library". From the README:
>
> "The psys library provides a simple interface to the system package
> managerof a Linux system. It allows installation programs to notify the
> packagemanager of the installation, uninstallation and update of
> third-partysoftware packages, and to request these packages to be added to
> or removed from the system package database. The psys library interface is
> generic and not tied to a specific package management system or Linux
> distribution.
>
> Note that the psys library is only useful for adding and removing software
> which complies to the Linux Standard Base (LSB) specifications. Most
> notably, it is assumed that the data files of a software package are
> installed into /opt as demanded by the Filesystem Hierarchy Standard (FHS),
> and that a package only depends on the interfaces and behavior specified by
> the LSB; any additional dependencies must be contained within the package
> itself.
>
> The psys library interface is strongly influenced by the Berlin Packaging
> API concept discussed at the 2006 LSB face-to-face meeting in Berlin. The
> library interface is meant as a proposal for a future version of the LSB
> standard."
>
> More information, including the complete API documentation and a link to the
> git repository with the source code, can be found on the project page [2].
>
> Now, I am asking you for support. While the psys library in its current form
> does, in fact, already offer basic integration into RPM- and Debian-based
> distributions through "fallback backends" (see the project wiki), the
> greatest level of integration can only be received if the implementation is
> provided by distributions directly. The question is: can you imagine adding
> support for a programming interface like this in your distribution? If not,
> why? And if you do, what do you think of the psys API in its current form?
> Where do you think it is lacking? Flawed? Complete BS?
>
> I am thrilled to hear your replies, and hope we can all together make
> something happen to improve the state of third-party software deployment on
> Linux.
>
> Best regards,
> Denis Washington
>
> [1] http://www.linuxfoundation.org/en/Berlin_Packaging_API
> [2] http://gitorious.org/libpsys
>
> P.S.: You might remember an earlier (2008), somewhat over-engineered attempt
> of mine to implement the Berlin Packaging API concept, the "Burgdorf
> Packaging API" (http://www.linuxfoundation.org/en/Burgdorf_Packaging_API),
> which spawned quite a lot of discussion at that time. Let me assure you,
> though, that the psys library is much simpler (and also already more
> advanced) in design and implementation than Burgdorf, and much lighter in
> terms of dependencies (libc, essentially).
> _______________________________________________
> Distributions mailing list
> Distributions at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/distributions
>