A modular package manager architecture

Abate, Pietro; Cosmo, Roberto Di; Treinen, Ralf; Zacchiroli, Stefano

doi:10.1016/j.infsof.2012.09.002

Cited by 23 publications

(21 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…1 A review of state-of-the-art package managers and their ability to keep up with evolution and their dependency solving abilities is offered in [1], with a proposal to treat dependency solving as a separate concern from other upgrade aspects. The upgrade problem is also considered in [2] to justify the design of a modular package manager. While we do not have an implementation of preferential settings based on user-choices, our installation profiles are defined according to a criterion of minimality for dependency satisfaction: this means that we construct installation profiles according to an ordered criterion of dependency satisfaction and package removal from a profile always proceeds to identify the minimal number of required packages.…”

Section: Related Workmentioning

confidence: 99%

Managing Software Uninstall with Negative Trust

Primiero¹,

Boender²

2017

Trust Management XI

View full text Add to dashboard Cite

show abstract

Section: Related Workmentioning

confidence: 99%

Managing Software Uninstall with Negative Trust

Primiero¹,

Boender²

2017

Trust Management XI

View full text Add to dashboard Cite

show abstract

“…As shown in Figure , a Configuration Model is automatically obtained by means of injectors, which are tools that are able to transform software artifacts (running FOSS Linux distributions in this case) into corresponding models in an automatic way. The Evoss approach injects a model (package model) also for each package that is part of the upgrade plan (as produced by a Planner, such as apt‐get or mpm ). The configuration injector is implemented by using the Eclipse Modeling Framework (EMF) , which queries the concrete system configuration and programmatically builds the configuration model.…”

Section: An Overview Of the Evoss Approachmentioning

confidence: 99%

A model‐driven approach to detect faults in FOSS systems

Ruscio

2015

J Software Evolu Process

View full text Add to dashboard Cite

Free and Open-Source Software (FOSS) Linux distributions are among the most complex modern software systems. They are made of thousands of components (software packages) evolving rapidly without centralized coordination. The upgrade of FOSS systems is managed by meta-installers, which solve package dependencies and conflicts and lead the system to a new system configuration by installing or removing packages. Current tools are able to predict a very limited set of upgrade faults before deployment, and this leaves a wide range of faults unpredicted. In this paper, we focus on faults that remain unpredicted, for example, missing packages, packages that are not properly installed, and missing services, with the aim of providing a solution for them. Specifically, in this paper, we propose a model-driven approach and supporting tools to prevent specific classes of system configuration faults before performing the real upgrade. Once the system configuration is represented as a model, the configuration model is evaluated by means of queries, each devoted to discover a specific class of faults. The approach is intrinsically extensible so that user communities can add new queries when new classes of faults are identified. The approach has been validated by executing the fault detector on configuration models in which faults have been intentionally injected and by analyzing produced results.

show abstract

“…A typical example of the metadata attached to a package is shown in Figure 2, where we can see that the logical language used for expressing dependencies and conflicts is quite powerful, as it allows conjunctions (symbol ','), disjunctions (symbol '|') and version constraints (the symbols '>=', '<=', '>>' and '<<' stand for the usual ≥, ≤, > and < operators); it is now well known that checking whether a component is installable is an NP-complete problem [2,4], though real-world instances are tractable [14,21,7,20].…”

Section: Packages and Repositoriesmentioning

confidence: 99%

Easing software component repository evolution

Vouillon

Dogguy

Cosmo

2014

Proceedings of the 36th International Conference on Software Engineering

Self Cite

View full text Add to dashboard Cite

International audienceModern software systems are built by composing components drawn from large repositories, whose size and complexity increase at a fast pace. Maintaining and evolving these software collections is a complex task, and a strict qualification process needs to be enforced. We studied in depth the Debian software repository, one of the largest and most complex existing ones, and we developed comigrate, an extremely efficient tool that is able to identify the largest sets of components that can migrate to the reference repository without violating its quality constraints. This tool outperforms significantly all existing tools, and provides detailed information that is crucial to understand the reasons why some components cannot migrate. Extensive validation on the Debian distribution has been performed. The core architecture of the tool is quite general, and can be easily adapted to other software repositories

show abstract

A modular package manager architecture

Cited by 23 publications

References 13 publications

Managing Software Uninstall with Negative Trust

Managing Software Uninstall with Negative Trust

A model‐driven approach to detect faults in FOSS systems

Easing software component repository evolution

Contact Info

Product

Resources

About