text: Inter-package conflicts require the presence of two or more packages in a particular configuration, and thus tend to be harder to detect and localize than conventional (intra-package) defects. Hundreds of such inter-package conflicts go undetected by the normal testing and distribution process until they are later reported by a user. The reason for this is that current meta-data is not fine-grained and accurate enough to cover all common types of conflicts. A case study of inter-package conflicts in Debian has shown that with more detailed package meta-data, at least one third of all package conflicts could be prevented relatively easily, while another one third could be found by targeted testing of packages that share common resources or characteristics. This paper reports the case study and proposes ideas to detect inter-package conflicts in the future.
  @cite_15: Component-based systems often describe context requirements in terms of explicit inter-component dependencies. Studying large instances of such systems — such as free and open source software (FOSS) distributions — in terms of declared dependencies between packages is appealing. It is however also misleading when the language to express dependencies is as expressive as boolean formulae, which is often the case. In such settings, a more appropriate notion of component dependency exists: strong dependency. This paper introduces such notion as a first step towards modeling semantic, rather then syntactic, inter-component relationships. Furthermore, a notion of component sensitivity is derived from strong dependencies, with applications to quality assurance and to the evaluation of upgrade risks. An empirical study of strong dependencies and sensitivity is presented, in the context of one of the largest, freely available, component-based system.
  @cite_3: Upgrades in component based systems can disrupt other components. Being able to predict the possible consequence of an upgrade just by analysing inter-component dependencies can avoid errors and downtime. In this paper we precisely identify in a repository the components p whose upgrades force a large set of others components to be upgraded. We are also able to discriminate whether all the future versions of p have the same impact, or whether there are different classes of future versions that have different impacts. We perform our analysis on Debian, one of the largest FOSS distributions.
  @cite_1: As organizations adopt component-based software engineering, it becomes essential to clearly define its characteristics, advantages and organizational implications. This report presents key discussion points from a workshop on CBSE and provides a useful synthesis of participants' diverse perspectives and experiences.
  @cite_7: The mainstream adoption of free and open source software (FOSS) has widely popularised notions like software packages or plugins, maintained in a distributed fashion and evolving at a very quick pace. Each of these components is equipped with metadata, such as dependencies, which define the other components it needs to function properly, and the incompatible components it cannot work with. In this paper, we introduce the notion of strong conflicts, defined from the component dependencies, that can be effectively computed. It gives important insights on the quality issues faced when adding or upgrading components in a given component repository, which is one of the facets of the predictable assembly problem.Our work contains concrete examples drawn from the world of GNU Linux distributions, that validate the proposed approach. It also shows that the measures defined can be easily applied to the Eclipse world, or to any other coarse-grained software component model.
summary: Seminal work by Mancinelli et. al @cite_1 has shown how to encode the installability problem for software packages as a SAT problem, established the (NP-Hard) complexity of the problem, and shown applications of the encoding to improve the quality of package repositories by avoiding non installable packages. Based on the same formalization, various quality metrics have been established, such as strong dependency and sensitivity @cite_15 (to evaluate the importance'' of a package in a given repository) and strong conflicts @cite_7 (to pinpoint packages which might hinder the installation of several other packages). In the same vein, package meta-data have also been used to predict future (non) installability of software packages @cite_3 . The abundance of studies that rely on package meta-data testifies the importance of the correctness of those meta-data.