4.3.1 Backward compatibility
This infrastructure does not require any modification to the current packages and their format. The information provided by the infrastructure can be used to com- plement or override the information that is hard-coded into package information metadata if the user requires so, but can be completely ignored otherwise.
4.3.2 Impact on the existing tools
The impact on existing tools is also minimal. During the package database infor- mation parsing phase, an existing tool could add to its internal representation the additional information coming from the external metadata servers specified by the users, after pre-processing the options into the internal representation of specially namedprovides tags. Once that is done, the usual algorithms for discovering a solution of the constraint could be used without modifications.
4.4
Remarks and related work
The previously described proposals entail several consequences. First of all, de- scribing new metadata information poses an ontology design problem. On the other hand, building an infrastructure for supporting the new features of the pack- age management and distribution system introduce the classic architectural prob- lems that we have when we build complex and distributed systems.
Of course these problems are out of the scope of this deliverable and even of the relevant topics addressed by Work Package 2. However it is interesting to point them out.
In particular, with respect to the ontology perspective, we cite the AMOS project [?] which addresses the problem of “building an ontology of open source
code assets and a tool which helps the programmer to select, among all the de- scribed packages, those which are more promising for developing the desired soft- ware”. This work is closely related to what we have described so far, even if it addresses a different (and more general) problem concerning software devel- opment and open source software categorization and search engines. However it could be interesting to investigate the adopted solutions in order to reuse them in our context.
On the distributed infrastructure side, instead, we must face the classic prob- lems related to information distribution, synchronization and trust. Actually these topics are closely related to the ones addressed by the EDOS Project Work Pack- age 4. This fact strengthen the relationships and the synergy between the different perspectives addressed by the EDOS Project.
Finally, it is worth to mention the W3C Member Submission regarding Instal-
lable Unit Package Format Specification[?]. This document describes an XML specification for describing installable packaged software units. Even if this ini- tiative seems to completely overlap the problems we addressed, actually it simply
EDOS Project: WP2D1 4.4. REMARKS AND RELATED WORK
proposes a meta format in order “describe a common installable unit package for-
mat [...] that is compatible with existing standard or de facto standard formats [...] and that encapsulates and uses the existing install technologies for the vari- ous hosting environments”. In practice it doesn’t address directly the problems we have with the description of fine grained features (such as package dependencies) but it only propose a generic and extensible way to describe high level package characteristics, leaving the responsibility of handling the actual problems to cur- rently available technologies. Nevertheless, the design solutions proposed in this work, can be useful for refining the specification of the metadata information dis- tributed using the infrastructure described in Section4.3.
Chapter 5
Conclusions
We have provided an in-depth presentation of many largely used package manage- ment systems, focussing on the dependency management issues, which are central to this workpackage of the EDOS project. Based on this analysis, we have been able to pinpoint some limitations of the existent formats, and to make a concrete poroposal for a new metadata infrastructure that is backward compatible with the existing formats.
The total backward compatibility of our proposal, its low impact on the ex- isting tools, and the separation of concerns between package managers and addi- tional metadata maintainers we provide is an essential feature to give this proposal a chance of being accepted in the real world, as those that will adpot it will reap all the benefits without imposing any burden on the rest of the community.
We have also shown that the constraint languages used in DEB and RPM pack- age description are sensibly equivalent, and that the associated installation prob- lems are both NP-complete. Hence, automatic package installation tools like APT, URPMI or SMART live dangerously on the edge of intractability, and must care- fully apply heuristics that may be either safe (the approach advocated by SMART), and hence not guaranteed to avoid intractability (in other words, in some cases the user may have to wait an exponential amount of time before getting an answer), or unsafe, thus guaranteeing an answer in limited time, but accepting the risk of not always finding a solution when it exists.
The detailed analysis of the algorithms underlying these existing tools, and a proposal for a state-of-the-art tool for automatic package management, both on the server side, to ensure consistency of whole package repositories, and on the client side, to ensure optimal management of a given installation, are now a clear necessity, and will be addressed in the next deliverables.