Mailing list: lsb-discuss at lists dot linux-foundation dot org
IRC: #lsb on irc.linux-foundation.org
Code License: GPL/BSD, specs: GNU FDL
Mentors: Alexey Khoroshilov (alexey dot khoroshilov at gmail dot com), Jeff Licquia, Denis Silakov (dsilakov at gmail dot com).
Distributing software for Linux is a known pain for many developers who want to provide their products in a compiled (binary) form for all users, not depending on Linux distribution they use. Even if developers are sure that application binaries will work properly on all necessary Linux implementations, they face several problems with proper program installation inside particular systems.
The first problem is a large variety of package managers that exist in the Linux ecosystem. However, package managers in most popular distributions accept packages of either DEB or RPM format; moreover, RPMs can be converted to DEBs using the 'alien' tool, so package formats by themselves is not a critical issue.
A more significant problem is different 'dependency' names used in distributions to designate entities that are actually the same. For example, if someone wants to create an RPM package for application that uses libQtGui, then it will be necessary to create several packages with different dependencies - the one for openSUSE that will depend on ‘libqt4’, another one for Fedora (requiring ‘qt4-x11’), the next one for Mandriva (‘qtguilib’) and so on. In some cases (including our example) a possible approach is to use direct dependencies on libraries, but this works for RPMs only and doesn't cover those dependencies that don't concern libraries.
Public services such as openSUSE Build Farm simplify generation of separate packages for different systems, but developers still have to create separate spec files for every distribution. Another approach is standardization - the LSB specification standardizes some packaging aspects, but the LSB approach is suitable only for LSB-compliant applications; unfortunately, LSB covers only a part of existing libraries and interfaces, and many programs are out of its scope. Other promising approaches such as Berlin Packaging API require support from distribution vendors and haven't got much popularity yet.
Thus, though some approaches and tools exist that help developers to resolve packaging issues, there is no unified and fully automated solution yet, and one of the problem of different dependency names in different distributions remains urgent.
Currently we are working on a web service providing access to a database with information about correspondence between dependency names in different distributions. At the moment, this information can be provided to users as plain text lists via web UI.
The goal of the proposed GSoC project is to develop more complicated tools that will simplify usage of the service by end users. Two tools are to be developed; the first one is a tool for application developers that will automate creation of rpm and deb packages for different distributions on the basis of one package (provided by developer) suitable for one particular system (by repacking files and transforming dependencies). The second tool is for end-users that will allow installation of 'alien' packages (created for other distributions) in user's system, querying the web service for necessary data and resolving transformed dependencies.
Desired knowledge: C/C, packaging basics, rpm and deb formats, Web services.
===LSB test result analytic system===
[[http://ispras.linuxfoundation.org/index.php/About_Distribution_Checker languages, annotations are usually used to perform static program analysis (see, for example, ACSL specification language or the splint tool).
The goal of this project is to add support for annotations to the API Sanity Autotest - the automated test generator should take such annotations into account and add appropriate runtime checks wherever possible; this should allow to significantly improve quality of the generated tests. First, support for splint annotations should be added; support for more expressive ACSL annotations is an optional task.
Desired knowledge: C and C, Perl, basic knowledge of code parsing techniques. ===Upstream Tracker=== The number of shared libraries in Linux ecosystem is permanently growing up. New versions are released very often, introducing new features and fixing bugs. However, new versions are not always compatible with previous ones (e.g., there can be changes in function behavior, in data type structure, etc.), so applications that use old versions can behave unexpectedly or even fail to run with new ones without recompilation. Information about compatibility between library versions is especially important for distribution maintainers, who should support synchronized set of libraries and applications and ensure that everything works fine in their systems. In particular, it is important to estimate if it is safe to update a particular library and if such an update will require rebuilding of other system components.\\ \\ Several tools exist that can be used to estimate compatibility of different library versions - e.g., icheck or ABI Compliance Checker. However, though these tools are useful when comparing two versions of some library, they provide no way to automate tracking of changes in a huge set of libraries that are used in modern Linux distributions.\\ \\ The goal of this project is to develop a system named "Upstream Tracker" which will provide information about libraries evolution from backward compatibility point of view. The two major components of the system to be developed are like the following: * a monitoring backend that will regularly check for updates of various Linux libraries from LSB Navigator [[http://dev.linuxfoundation.org/navigator/browse/rawlib.php?cmd=display-approved , Perl, Web services, knowledge of compatibility basics.