 |
 |
|
 |
|
|
|
LSB Navigator Help
LSB Navigator provides a web interface for browsing the LSB Database. The database data can be changed through the 'Administration' page, but the online access to the 'Administration' mode is restricted.
Help Contents |
General Information
LSB Database is a central place for storing information about the LSB standard and about the surrounding Linux ecosystem. LSB Navigator represents web based interface over all these information. It can be used by Linux developers, Linux distribution vendors and LSB workgroup to browse, query, analyze and submit various information.
From this database, several portions of the specification itself are generated. This eliminates hand editing, and helps insure that the specification is always in sync with decision that have been made. Also produced from this database are some of the test suites, and portions of the application checking program lsbappchk. By pulling all of these from the database, we can ensure better consistency across different parts of the LSB.
Furthermore, the database contains information about applications (which interfaces they use) and distributions and components (which interfaces they provide).
LSB Elements Section
This section contains information about all elements that appear in the specification text. The main part of the LSB is ABI (Application Binary Interfaces), but there are also Commands, ELF and RPM elements. All elements are joined into Modules.Modules Section
Modules are the top level entities in the database - Libraries and Commands are logically joined in different modules. ELF and RPM Elements belong to LSB-Core module.
Some of the LSB Specification Modules on the database level are separated into several SubModules.
ABI (Libraries) Section
ABI (Application Binary Interface) is the main part of the LSB Specification. It defines Interfaces that should present in all LSB-compliant distributions. If an application uses only such interfaces, then this application is LSB-compliant and will run on every LSB-compliant distribution (one should remember here that LSB-compliance is architecture dependent and application or distribution that meets LSB requirements on one architecture can fail to meet these requirements on the others). Interfaces are joined in Libraries they are provided by and Classes they are included in (if any). Moreover, although LSB is a binary level standard, it is necessary to know some information (at least header and synopsis) for each interface. For these purposes the database has special tables, Type and Header, which contain types and headers required by interfaces from the LSB. There is also Constant table where different constants use by interfaces are stored. There are logical subdivisions of headers and libraries, called Header Sections and LibGroups respectively.
Commands Section
The LSB Specification defines some commands (including shell built-ins). Some commands are described in the LSB itself, for others the specification references other standards. Direct link to a detailed command description can be obtained after clicking on a command name - after that you will be redirected to the selected command's page with a short summary.
ELF Elements Section
LSB defines some objects related to Executable and Linking Format. In particular, it defines valid ELF Sections descriptions with detailed description of each section and of each Section type. In addition, the specification contains definitions of Dynamic Entries. All ELF elements belong to LSB-Core module.
RPM Elements Section
LSB also contains descriptions of valid RPM tags. This information is used in order to automatically generate tools that can check rpm packages for compliance. All RPM elements belong to LSB-Core module.
Interpreted Languages Section
In addition to binary level interfaces, LSB also specifies some aspects of interpreted languages usage. Currently, interpreters location, their minimal versions and a set of modules that should be provided are specified. All interpreted languages belong to LSB-Languages module; every language has its own submodule (e.g. LSB_Perl and LSB_Python).
Distros and Apps Section
This section contains information about distributions, their components, libraries, interfaces and classes. For applications, there are lists of libraries and interfaces that should present in the system in order to make the application work correctly.
All data presented in this section is collected by special scripts using 'readelf' command.
Applications
This section contains information about libraries and interfaces required by applications. Such information is obtained using 'readelf' output for the application executables and shared objects. Using readelf, it is possible to detect which interfaces required by the application are provided directly by the application's shared objects and which should be dynamically linked from the system's libraries.
On the main page in this section for each application number of such 'external' interfaces and libraries is shown. In order to get detailed lists of interfaces or libraries one should click the appropriate 'list...' link. In the list of interfaces LSB status for each interface is shown, so it is easy to say how many non-LSB interfaces the application uses.
Distributions
This section contains information about contents of different distributions - their components, libraries, commands and interfaces. From the database's point of view, each distribution is simply a set of components. Note that not all components that really present in a distribution may be uploaded to the database.
Components
Components are logical groupings of libraries. For example, 'Qt4' component contains all libraries forming Qt4 (libQtCore, libQtNetwork, libQtTest, libQtXml, ...). For each component, number of classes and interfaces is shown. Detailed list of classes or interfaces can be obtained by clicking the appropriate 'list...' link.
Libraries
This section contains libraries provided by different components and presented in different distributions. For each library, number of classes and number of interfaces is shown. Detailed list of classes or interfaces can be obtained by clicking the appropriate 'list...' link.
Libraries provided by components are stored in the RawLibrary table.
There is a set of approved libraries - we check every uploaded distribution for such libraries presence and collect data about all interfaces exported by them. Libraries not included in the approved list can be actually present in the distributions where they are reported to be absent by Navigator.
Commands
Here the commands are collected provided by different components. Among these commands one can find not only ELF executables, but also different scripts (Perl, Bash, etc.). If the command is, in fact, a script, then the kind of this script is shown in the 'Comment' column. This kind is guessed automatically during upload process using 'file' command. The situations are possible when 'file' doesn't know anything about a script, and in this case the script doesn't have any kind in 'Comment'.
Note that it is possible to click on the command's name and to get a page with short information about command - if it is included in the LSB and in which distributions it presents. Furthermore, for some commands included in the LSB links to documentation are available.
Commands provided by components are stored in the RawCommand table.
There is a set of approved commands - we check every uploaded distribution for such commands presence and collect all data about them. Commands not included in the approved list can be actually present in the distributions where they are reported to be absent by Navigator.
Classes
This section contains classes provided by different components and used by different applications. Note that all information about classes is also collected automatically using readelf and the thing is that it is impossible to distinguish a class from a namespace on the binary level. Therefore one can find namespaces among these 'classes'. We call these classes 'Raw Classes' and in the database they are stored in the RawClass table.
If a class was found in a component, then information about this component is shown (i.e. component name, version, distribution if this component was uploaded as a part of distribution), library where the class is situated and number of interfaces in the class. Detailed list of these interfaces can be obtained by clicking 'list...' link.
Interfaces
This section contains interfaces provided by different components and used by different applications. For each interface number of distributions, components and libraries is shown where this interface presents. Detailed list of distributions, components or libraries providing the interface with the given name can be obtained by clicking the appropriate 'list...' link.
Not all possible components are uploaded to the database, so for some interfaces one may see zeros in all columns. This fact means that some applications registered in the database use this interfaces, but none of the registered components provides it.
The name of each interface is a link to so called Single Interface page. On this page one can see the summary for the interface with the given name - its history in the LSB, its synopsis (according to the LSB), link to documentation (not for all interfaces, since not all specifications referenced by the LSB are available online). Furthermore, there is some statistics about distributions and components that provide this interface and applications that use this interface. Detailed list of applications can be obtained by clicking the appropriate 'list...' link.
Workgroup Services Section
This section provides different statistic data and some useful information concerning LSB infrastructure.Statistics
This page provides historical statistics for LSB elements (libraries, classes, interfaces, etc.) as well as for commands and headers. The page shows number of elements in every LSB version, with the availability of getting full list of elements of a certain kind included in a given LSB version.
Tests and Coverage
Tests and Coverage page contains information about test suites and coverage provided by them. Three grades are used to classify test coverage level for each interface:
- Deep - this is the level when most of the specification assertions are tested in various conditions/states.
- Normal - the main functionality of the interface is checked and maybe a few error scenarios.
- Shallow - simple tests with the only guaranteed purpose of ensuring the interface does not crash. Only critical errors in the interface are caught by this.
Standards
The LSB Specification itself contains description of only a few interfaces. For others it contains only references to the existing standards and specifications. This section contains a list of existing standards referenced by the LSB Specification. For every standard, detailed lists of interfaces, commands and ELF section types can be obtained. Note: If you see zeros in all columns (no interfaces, commands or ELF sections are assigned to this document), it doesn't matter that the document is superfluous - some documents are referenced in some specific places not reflected in the database. Note that sometimes LSB description contains only differences with respect to some other specification; in such cases LSB is marked as 'main' standard, and referenced specification - as 'referenced' one.
Linux Application Analysis Center
This section provides tools for analysis of libraries, interfaces and modules of interpreted languages used by various Linux applications. This is to support decision making for developing future LSB versions (generally, frequently used interfaces/libraries may be added to the standard while unused ones may be removed).
Applications in this section can be filtered by their size, kind of user interface, licensing type and vendor:
- Application Size
Applications can be classified as 'Small', 'Medium' and 'Large', depending on the number of external interfaces they use:
- Small applications use less than 100 external symbols.
- Medium - from 100 to 999 interfaces.
- Large - 1000 and more.
- User Interface
All applications are divided on GUI and non-GUI. Applications which have both graphical and command line interface, are treated as 'GUI' ones. - License
Application licenses are divided on Open Source, Proprietary and Mixed. Applications with 'Mixed' license have both open source and proprietary versions of their product. Note that open and proprietary versions of the same product can require different external symbols.
- Application Vendor
Using this filter information can be obtained concerning applications of a specific vendor. Note that for many open source applications uploaded from distributions the vendor of distribution is mentioned as 'application vendor'.
- Application Category
Categories are set on the basis of application functionality. The following categories are used at the moment:
Category Description Accessibility and i18n Accessibility, internationalization Antivirus and Security Antivirus, content security, content filters, cryptographic applications Emulators Emulators Office and Desktop Text Processors (like OOo) and more simple editors (like joe) including supplementary tools, viewers for different documents (like xpdf and advi), spreadsheats (Gnumeric), calendars and organizers (Sunbird), finance apps (eqonomize, kmymoney), dictionaries (dict), file managers (dolphin) Data Management Database servers, clients, frontends and misc utilities. Different information managers (Beagle, Google Desktop) Development Compilers, interpreters, libraries for developers, IDE, profilers, debuggers Games Games Multimedia and Graphics Audio/video players and editors, image viewers and editors, multimedia libraries, 2D/3D modelers Network All things concerning network - [tcp|ftp|http|...]demons/servers, web and mail clients, tools to connect mobile devices Science and Education Science and Education System Tools System tools and libraries, shells, archivers, administration and backup tools X11 Utilities X11 window managers, middleware, libraries, terminals, utilities - Count Rejected Elements
Another kind of filters is 'Count Rejected Libs/Ints' checkboxes. They allow to filter out libraries and interfaces that are not considered as LSB candidates. Usually these are old versions of libraries (e.g. GTK-1 libs), internal symbols with unspecified behavior or symbols not recommended for standardization by upstream developers.
Futures Tracker
The LSB Futures Tracker represents activities on adding new elements to the Linux Standard Base specification, as well as activities on updating information about existing components. FT consists of the two main sections: New Components Tracker and Uplift Tracker. New Components Tracker covers top-level entities such as libraries, interpreted languages, etc.
The process of adding a new element involves three phases called Identification, Investigation and Implementation. Every phase consists of several tasks. The state of every task is described by a flag that indicates if the task is completed and does its result allows to proceed with introducing a new element to LSB. More precisely, every flag can have one of the following values:
- Yes or Ok - The task is completed and no problems were found that would prevent addition of appropriate entity to LSB.
- No or Issues - The task is finished and some problems were discovered.
- Unknown - The task is either not started or the final decision on its result is not made yet.
- In progress - The task is being executed at the moment. This state is usually used for technical tasks such as adding new data to the specification database, creating new tests, etc. - i.e., the tasks that should not introduce any problems but that can take some time.
Every task from the first two phases should check certain criteria that LSB candidates should meet. The 'Implementation' phase tasks are mostly technical activities on actual addition of a new element. The whole list of the tasks is like the follows:
| 1. Identification | |
|---|---|
| Demand | There needs to be sufficient demand for the component to be standardized. Demand can be measured in many ways. For example, heavy usage of a component in the community or multiple requests from developers. Keep in mind that, while there may be demand for many things, not all will meet the additional criteria. |
| License | The component should have at least one compliant implementation available under an Open Source license that also promotes a "No Strings Attached" environment for developers. This means that the developer would be able to develop and deploy their software however they choose using at least one standard implementation. This is interpreted to mean that at least one implementation is available under a license that meets the Open Source Definition but is does not prohibit proprietary usage. The rationale for this criteria is very similar to that of the LGPL. |
| Bestpractice | The LSB candidate must represent the "best practice" in the development community for the problem it solves. It needs to have emerged as a clear de facto standard and be available on all major distributions. |
| Stable | The API/ABI of the candidate is required to be stable enough to target for standardization. The maintainers should guarantee the backward compatibility of their components (for those elements that are going to be included in LSB). |
| Depends | The candidate's runtime dependencies should either already exist in the LSB, are planned to be added, or abstracted away so that specifying their interfaces is not required. Dependencies provide insight for things that may need to be added and/or potential problems that may be encountered. Recursive dependencies should be listed and discussed before proceeding. |
| 2. Investigation | |
| Rationale | The rationale for the why the component was added and for all parts of the specification should be recorded and published. Mailing lists and meeting minutes are not sufficient, this data needs to be recorded in the specification or a separate document. Lack of rationale documentation has already been a problem with older versions of the specification, so this is very important. |
| Upstream | The upstream maintainers must be committed to backwards compatibility (for some defined version) and stability. They should be willing to work with developers and distributors on providing a standard everyone can agree on and adopt. |
| Distros | The component maintainers for the distributors should be willing to work together. They should be willing to work with upstream maintainers and developers on providing a standard everyone can agree on and adopt. |
| Versions | The upstream maintainers, distributions, and developers should be synced up on compatible versions. If not they should be willing to agree on and adopt compatible versions. |
| Patches | If the distributions maintain any patches against the component, these could be merged upstream or dropped. Since the LSB is a behavioral standard this is not required but could make things easier. |
| 3. Implementation | |
| Db | Import the component into the LSB database as a first step for working on the spec/tests/devel/sample. |
| Spec | Development/adaptation of the written specification for that component in the proper format for integration into the LSB specification. |
| Test | Development/adaptation of the test suites for that component in the proper format for integration into the LSB test suite. |
| Devel | Generation of stub libraries and usable headers for the LSB SDK. |
| Sample | Build of the sample binaries for that component in the proper format for integration into the LSB sample implementation. |
| Appbat | Selection of application that uses the component to be included in the Application Battery. |
The 'New Component Tracker' main page contains 'Show Completed' filter that allows to display or hide data about completed tasks.
Every LSB candidate can have some libraries associated with it. Information about these libraries (usage by applications, presence in distributions) can be obtained by clicking 'statistics...' link in the 'Libraries' column.
The Uplift Tracker section can be used to investigate uplift possibilities for libraries that are already included in LSB. Its main page contains a list of all libraries included in the latest LSB version is presented, with number of included interfaces (a union of generic and all arch-specific entries is calculated). The 'Uplift Planned' column reflects general plans about library uplift in the next LSB version (the state is taken from the UpliftTarget table).
The 'details...' link in the 'Uplift Planned' column can be used to obtain detailed information about library interfaces that can be considered as candidates for the next LSB version. More precisely, a list of interfaces is constructed that were absent in distribution targets for the previous LSB version, but which are present in all distribution targets for the next LSB version. Interfaces are ranged according to number of applications they are used by, and for every interface detailed list of such applications can be obtained.
Filters
There are two main filters in the LSB Navigator - LSB Version and Architecture. They are visible only in those sections where they make sense. There are also Distribution and Component filters in the Distros and Apps section that allow to filter content by Distribution or Component name correspondingly. AppStats section contains a lot of additional filters (see above). Finally, Count Unofficial filter can be used to control whether unofficial distribution releases should be taken into account when analyzing presence of some element in distributions.
Note: To make filters work properly, you should have cookies enabled. Otherwise the filter values will be lost every time you change the page.
Architecture filter is available on almost all pages in LSB Elements and Distros and Apps sections, except pages where summary information for sense of page, e.g. Interfaces in 'atk-1.8.0-2' Component in 'Asianux 2.0' Distribution on x86 Architecture, the given element is collected and some title pages. On those pages where the architecture is predefined by the the architecture filter is disabled (and is frozen to the value it had before going to the page).
Also note that a lot of elements can have different contents on different architectures (e.g. headers contain different sets of constants and types). When 'No filter' is selected in the Architecture filter, then the union of all arch-specific contents is displayed. In this case, number of entities contained in the element (e.g. number of constants in header) is the number of entities with different names (e.g. duplicates in unions are not counted), but when displaying contents in detail, all duplicates are also displayed (since they can have different properties on different architectures), so the number of entries displayed can be greater than the number of entities.
When a specific architecture is set in the Architecture filter (i.e. neither "No filter" nor "Generic"), records belonging to this specific architecture and to generic one are counted and displayed. But if there is a record for the same entity for both generic architecture and for the selected one, then only record for the selected architecture is taken into account.
LSB Version filter is available only on pages from LSB Elements sections, except those where summary information for the given element is collected and some title pages. When this filter has not '*No filter*' value, only elements are shown (and counted) which are included in the LSB specification of the selected version. Otherwise all elements ever included in the specification are displayed.
Search
In the upper left corner the 'Search' toolbar is situated. Using this search one can find an interface, a class, a library or other element stored in the database by selecting appropriate element type from the combobox. One can select Everywhere search target to search among all main tables in the db. Search results always contain exact matches (if any) at the top.
For interfaces and classes, the search is performed in both mangled and unmangled names. For libraries, we are looking for matches in libraries' names and run names. Note that there are interfaces with the same names in different libraries and described by different specifications (this is the common case for Qt interfaces - Qt3 and Qt4 have a lot of interfaces with the same names). Such situations are handled successfully during the search process - if there are different interfaces (from different libraries) with the same name, separate records will be included in the search results, each followed by a library name the interface belongs to.
For types, the search engine is aware about type specifiers and takes them into account. So one can enter, for example, 'strcut foo' to look for structs with 'foo' in their names.
Each search result is a link to the element 'home' page containing a short summary for this element.
For Everywhere search, number of results displayed for each category is limited to value specified in the appropriate filter. Currently we don't allow to display more than 100 elements in every category. We believe that this is enough in most cases; if you want more results for particular kind of elements, you can select that elements in the 'Find' combobox.
Help
Contains the description of the LSB Navigator (the page you are reading now).
About
Contains the general information about LSB Navigator: its version, license etc.
|
||
|
||
|
||
|