- 1 Table of Contents
- 2 Requirements Analysis
- 3 Comments
- 4 Notes after lsb-futures call
- 5 Relevant Pages
- 6 User Comments
Table of Contents
1. Why is such a tool required? BR
- Present distributions use tools like "
chkconfig" and "
sysconfig" for most configuration related requirements
- these tools, though prevalent in multiple distributions do not perform the tasks listed out for lsbinstall.
- The Distribution maintainers implement extensions to their installer application/toolsets to handle (eg.Yast for SuSE) what "
lsbinstall" is listed to do.
- Most distributions ship a "coreutils" package that provides /usr/bin/install which can just install files in a destined path with permissions, but does not achieve tasks allocated for "lsbinstall".
- Many packages use install-sh which is originally from the X tree.
2. What tasks does the "lsbinstall" tool need to perform? BR
- the lsbinstall tool needs to "install", "check for installation" or "remove if installed" the following:
- profile scripts (which are executed when users login) - also specified in FHS
- most distributions place these profile scripts under
/etc/profilea script that executes all scripts within this path.
- profile scripts are presently installed by a simple copy and permission set, using custom
- execution is ensured by adherence to FHS standards (updating
/etc/profilewhich is part of the standard).
- enable and disable features are not normally supported by standard package installation toolsets for profile scripts.
- services: (under FHS
- The package "netcfg" in most distributions provides /etc/hosts, /etc/protocols and also known services under /etc/services.
- enabling and disabling services is usually done by a "postinstall" script of any installable package.
- inet services: (under FHS /etc/inetd.conf) or optionally /etc/xinetd.d. Many distributions use xinetd (although not FHS compliant.)
- no specific tool is provided (and is usually custom per distribution) for installing new inetd services.
- for each component installed, prevent namespace issues, collision by using LANANA and package-component_name naming schemes
"Extended Uses" proposed: BR
- extended uses were proposed including the following:
- font installation: (This depends on X11 (R6.8.X), irrespective of the desktop being used.)
/etc/X11/xorg.conf:Section "Files":[[FontPath]] "path"for specifying installed font search paths.
- Freedesktop also outlines and provides fontconfig for font management across desktops.
- fontconfig usermanual describes fontconfig as a mechanism of managing, maintaining fonts and font-matching issues. However "installation" and "removal" of fonts is not explicitly a function of the fontconfig toolset.
- modifying config files in the fontconfig tool-set would allow us to add or remove font install paths and explicit font names, but this needs to be done explicitly by another commandline tool.
- Unix Font Rendering explanation from freetype.org explicitly mentions how X11 handles fonts to understand relevant issues.
- menu installation: (This is dependent on the "Desktop Environment" [GNOME/KDE/...] which would include Desktop environments supported by the desktop-wg.) Freedesktop menu installation covers this issue.
/usr/share/applicationsis to contain
*.desktopfiles according to this specification. Both GNOME 2.10 and KDE 3.4 (and future releases) have started following this.
- no explicit tool is provided for menu installation, hence the application packager explicitly (as per desktop, distribution used) places the *.desktop file providing the menu entry in the relevant directory/category (under
- *FHS* specifies only
rcscripts are presently placed in
/etc/init.d/rc[0-6].ddepending on their execution requirements
- standard arguments for rc scripts followed implicitly include "
start, stop, restart, reload" with other extensions allowed.
- many rc scripts use distribution specific shell scripts or functions for graphical or text display of status reporting and logging.
- "chkconfig" allow scripts copied by a package installer to
/etc/init.dto be added or removed from relevant run levels.
- The package's installation script needs to ensure that init-scripts installed by it follow a specific format that chkconfig recognises to allow this.
- man pages
- presently, installers of packages, copy relevant manpages to
/usr/share/man/man[number]making them available. So long as standard paths are specified, installation of man pages should be simple. This is specified in FHS.
- mandb needs to be updated running
/usr/bin/mandbusing a cron job or updated on package installation by the package post-install scripts.
- "enable installed component", "disable installed component" features
- all components mentioned above can be "enabled" (made active and functional) or "disabled" (temporarily commented out or moved out of search paths.) There is no single tool spanning all the above components for this. (eg. chkconfig can do this for "init" scripts.)
- ld library paths
/etc/ld.so.confaccording to *FHS* provides a list of search paths for ld libraries.
/sbin/ldconfigcan update the "current" shared library cache.
- Some distributions use
/etc/ld.so.conf.dwhich is *NOT under FHS*
- cron jobs
- FHS does NOT propose
/etc/crontabas the table followed for scheduling tasks, but a majority of distributions follow this as implicitly.
- FHS reserves
/var/cronfor cron pid and cron job tmp purposes and
/var/cron/spoolfor tasks, however that "reservation" remains unused by SuSE, Mandriva and RHEL.
/etc/cron.monthlyare used by most distributions and default entries to execute tasks within them are written into
/etc/crontab(this too is not under FHS specifications)
- FHS provides
/var/cronand /var/cron/spool for "
cron" and "
at" tasks, although a location for the crontab in itself is not specified. This is followed by most FHS compliant distributions for task spooling.
The first two items, for ownership have been transferred to desktop-wg (Rajesh) to confirm inclusion/exclusion. For the rest however, the above "extended uses" are not decided features due to LsbinstallProblems lack of consensus. Rajesh has also mentioned that the entire scope and need of the tool (consented and extended functions included) are under review. BR
- These mechanisms are exposed to application packagers for distributions.
- Most distribution provide a packaging guide to assist the application packager.
- In a majority of cases, application packagers are not the upstream maintainers of a package.
- Hence, many "source packages (src.rpms or srpms or sources specified by .deb packages) include patchsets to deal with distribution specific issues.
- Namespace issues are conveniently avoided in present distributions as most of them have packages tailored specific to them. However cross installing LSB compliant packages across distributions will be where namespace issues would creep in.
- autoconf can perform many the listed functions (for an application packager) except, font and menu issues.
- Application packager's for most of the distributions being considered in the LSB effort manage to use autoconf or an alternate install method while packaging.
- Files inside packages to check out:
Makefile.inusually has the packager/application maintainer write installation specific options that will later be translated by macros into the final Makefile. Some preliminary checking is done in
Configure.in. Any package using auto(conf|gen|make) will illustrate this. (I am refraining from an in-line example to avoid bloating this Wiki.) Many packages use a legacy
install-shwhich is from the original X11 tree.
|Install tool overview|
|SuSE||Yast/network services||inetd services installation/removal|
|SuSE||Yast/Runlevel editor||/etc/services (enable/disable)|
|SuSE||KDE-control-centre/System Administration||font installation/removal in KDE|
|SuSE||gnome-font-install||font installation/removal in GNOME|
|SuSE||Yast/system/runlevel editor||init.d/rc scripts (enable/disable)|
|SuSE||chkconfig||init scripts (enable/disable)|
|SuSE||fontconfig||font management (by config files)|
|RHEL||KDE-control-centre/System Administration||fonts installation/removal in KDE|
|RHEL||gnome-font-install, nautilus fonts://||font installation/removal in GNOME|
|RHEL||redhat-config-services||init scripts, xinetd services installation, configuration|
|RHEL||fontconfig||font management (by config files)|
|RHEL||chkconfig||init scripts (enable/disable)|
|NLD||control-centre/System Administration||KDE-Yast functions, installation/removal of fonts, service management, init scripts|
|Mandriva||TheDrakes The Drakes||System: font installation/removal, init scripts enable/disable, cron jobs install/remove, menu installation/removal, server wizards: network services installation, management|
|Ubuntu||bum||init scripts (start, stop, enable, disable)|
|Gentoo||domenu||menu installation (freedesktop standards)|
Note: The majority of the above listed tools target the "System Administrator" group and not the "Package Manager" or "Package Installer".
- NLD resorts to YaST2 Yast as does SuSE for most installation and configuration related tasks.
- A key point to note is that these tools are almost exclusively implemented as "scripts" to ease installation.
- Most of the above tools are intended for the "System Administrator" rather than the "Package Manager" [or] "Application Packager".
- the task of configuring is supported by many tools, while the task of installing the components covering the said functions is left to the package builder/maintainer (for profile scripts, init scripts, inetd/xinetd services, /etc/services, crontab, manpages, info documentation and a host of other functions extending those considered for lsbinstall.)
The motivation of this table is to point out that each distribution has implemented the functions, but using an array of disparate tools. Unifying them into one tool can make the "LSB Compliant Application Packager"'s work simpler.
3. Who will use (or depend on) such a tool?
- Package Managers building "LSB Compliant Packages", who require to install services will be able to use this tool irrespective of the distribution targeted (so long as it is LSB compliant).
- Installation programs of newer distributions (signing up for LSB Compliance) can use lsbinstall instead of in-house tools, to target tool on core "system preparation" and "package installation" tasks.
- System administrators working on "LSB Compliant distributions" for installation tasks (of described nature) which they would like to keep track of (and avoid hand-editing.)
4. What are possible scenarios where "lsbinstall" can be completely excluded?
- Most package managers depend on "autoconf" based source tree management, and autoconf is extended to provide font, menu support as listed in the freedesktop specifications (to be adopted selectively by desktop-wg).
- Some packages depend on "imake" (xmkmf, etc.) and may require more hand-coding in their build/make structure to fit within standards.
- lsb-futures decides that package managers may be allowed the freedom to choose methods (hence tools/applications) for installation so long as LSB guidelines are adhered to. (This may increase the load on package testing for compliance.)
Relevance: BR PlenaryMeeting2005 from the Plenary Meeting - 2005BR lsbinstall discussion: the general consensus seemed to be to specify paths and utilities required for postintallation wherever possible, rather than to continue inventing additional utilities (i.e. lsbinstall). We should only go with lsbinstall if there really is no alternative. One participant offered the opinion that this was one space where if a standard provided guidance to distros on where to put things, they would follow it, even if it was a change from their current practice.
Comments: BR The LSB "Sample Installation" will still require a tool to perform the above functions, even if a "command line utility" such as "lsbinstall" were not part of the LSB Standard for distributions.
5. What are the available options in going ahead with lsbinstall? Anchor(options)
- The first option is to draft standards for application packagers (more like extending both FHS and Freedesktop standards) which LSB Compliant packagers will strictly adhere to.
- 2. The second option is to provide a tool and explicitly state that LSB compliant packagers will need to "use" the tool, and hide the standards within the tool.
- 3. The third option is to provide both the standards and the tool, and provide freedom to the LSB compliant packagers.
Present Design of Prototype Tool
- Mats Wichmann (python prototype, outdated)
- Nick Stoughton (perl prototype)
- Rajesh Banginwar (perl prototype)
- Refer: LsbinstallProblems Lsbinstallproblems for consensus issues and issues that have not been sorted out.
- The tool is documented in its present form at Lsbinstall@LSB-Core-spec
Requirements Specification Document
- [attachment:lsbinstall_req_specs.pdf Lsbinstall Requirements Specification (PDF)]
- [attachment:lsbinstall_req_specs.odt Lsbinstall Requirements Specification (Oasis Docbook Format)]
- UML Class, Use Case Diagrams
- [drawing:lsbinstall_perl Class Diagram]
- [drawing:lsbinstall_perl_use_cases Use Case Diagram]
- [attachment:lsbinstall_perl_design.xmi UML .xmi file] made with Umbrello
- [[[DistroIssuesLSB]]-wiki.txt Distributions Adopting LSB] - a emacs-wiki / emacs-mule text file explaining the rationale as to why a distribution would choose to implement "lsbinstall" as a easy means of getting LSB compliant.
- Legend: "Cyan" indicates extensible components whose ownership is with "desktop-wg" but are not inside the present implementation.
What are the next steps with the Lsbinstall tool?
The LsbInstall tool was removed from the Lsb-Core package during the PlenaryMeeting2005. The objects for "lsbinstall" and the inclusion of the "lsbinstall" command line were re-considered by the "futures" and "desktop" workgroups ( DesktopWg ). Following discussions, a revised specification for the tool was proposed and a mail announced this on the relevant lists.
The Rationale for the tool are:
- LSB compliant and LSB non-compliant packages will need to co-exist in a distribution without increasing the complexity to the "LSB Compliant Application Packager".
- Namespace issues for an LSB compliant package during install/uninstall time will be handled by hiding/abstracting them from the "LSB Compliant Application Packager".
- Distributions supporting "LSB Compliant Packages" will need a flexible tool allowing inclusion of new objects (for install/removal) by the maintainers in case there is an extension or deviation from FHS/LSB standards to hide/abstract these deviations from the "LSB Compliant Application Packager"
The above rationale stand good so long as distributions are on a roadmap to become completely LSB Compliant. Ultimately once a distribution is completely LSB compliant a specific tool/abstraction for installing/removing listed objects may not be necessary [please comment]. This has been mentioned in the "revised specifications document."
The Primary Objective of "lsbinstall" BRTo provide an abstraction (namely a command-line tool
lsbinstall) for installation/removal of a set of "objects", thus rendering the task of an "LSB Compliant Application Packager" easier. (In comparison with having to write one's own scripts and tools to maintain LSB compliance and avoid namespace collision.)
The issues on which decisions need to be taken with implementation of the "lsbinstall" tool are:
- Identifying and deciding the objects that all distributions will necessarily support for installation/removal using lsbinstall.
- Identifying objects that might "optionally" require to be supported for installation/removal using lsbinstall by a Distribution.
- identifying the package which will provide "lsbinstall" command-line tool.
Factors affecting necessary and optional objects would include:
- Distributions intending to be LSB Compliant which do not package "Desktop packages" (in which case desktop relevant objects like fonts, menus may not require support).
- Extent of LSB Compliance that can be achieved initially by a distribution directly impacting the complexity of the post install/uninstall scripts written by a "LSB Compliant Application Packager".
Presently, the sample implementation originally created by Nick Stoughton is being extended to support objects and a specification based on earlier proposals, consensus and all discussions relevant has been drafted for approval. Please check /ListDiscussions for mailing list conversations on the "lsbinstall" command line tool.
Notes after Desktop-wg Conference Call
Meeting Minutes from Rajesh.At the conference call on Tuesday
- we agreed that
/etc/profile.dwasn't part of FHS and only
- inetd (FHS) and xinetd (non-FHS) were being alternatively used by different distributions
- menu installation is quite standardised by adherence to freedesktop's requiring them to be placed on
- font installation may require the font to be added to
/usr/X11R6/fonts/font-type-path/*and an explicit mkfontdir in that path which may be done by a post-install script (by rpm) (ownership: desktop-wg)
- however, font installation into a non standard directory may require changes to
/etc/X11/xorg.confto add the new path the font-search-path and invoking
- if fontconfig is used to assist in fontmatching issues, fontconfig's config file will need insertions/deletions and a post-install run of fc-cache. However Rajesh said that the fontconfig candidate was being looked at from a pure library perspective.
- insertion/deletion from within text(config) files and commenting/uncommenting are issues that add complexity/difficulty to package managers while writing post-install scripts (and post-uninstall scripts).
ld.so.confhas a specific way to sort out issues, and new library search paths are easily included and
/sbin/ldconfigduring post-install could update caches and sort out the problems
- man pages are also covered by FHS as to the specific paths, hence running mandb to update the database during post-install should suffice the package manager to enable the man page.
- also discussed that
fontconfigassisted in font matching by faking font entries for an existing X server which was an issue.
- fontconfig, freetype were being listed as incoming candidates - Rajesh commented that this was from a pure library perspective.
- init script locations seem to vary from distribution to distribution unless they use an
chkconfigto assist in inclusion of the script under various runlevels
- Rajesh mentioned that FHS cannot be forced on LSB compliant distributions nor will it handle all necessary path issues, and distributions would still have room to set path standards for their specific tools/packages.
- This basically forces the distro independent packager to look at each distributions path configuration which is infeasible, and is potentially an issue that lsbinstall can solve. - this is the issue that lsbinstall solves in favor of the Application Packager.
- Further, adding "lsbinstall" functions as macros into rpm was not invited as a feasible or desired option. Everyone seemed to agree that a separate tool would still help at the postinstall script phase.
Summing the reasons above, the objects that would need to be handled (for update during install/uninstall) by the tool to make post install scripts for an LSB compliant application packager simpler and easier to work with are:
- profiles (
- services (
- inet services
- init scripts
Primarily the Application Packager or Package Manager would have a simpler job in terms of writing post-install scripts when he was packaging a distro-independent (LSB compliant) package.
Notes after lsb-futures call
- We discussed that among the three options
- [#options option] #3 (create lsbinstall and still allow the package manager/installer to follow standards in alternate methods "also" if possible) would be ideal.
- ref: Mats mail mentioning that it suffices that lsbinstall provides interfaces for different distros to perform listed functions on the selected objects.
- ref: Nick's proposal that one issue that necessitated the tool was the possibility of LSB compliant Applications "co-existing" with Non LSB compliant Applications, in which case the LSB compliant packager still needs a solution to stay LSB compliant and avoid standard violation (during installation/uninstallation.)
- Pradosh added that if #3 were the case, it would be possible if decided at a later stage, to adopt options #1 or #2 if a strong case was present to do so.
- Objects can be added to lsbinstall in a flexible manner as Nick's prototype design has already suggested.
- List of objects presently considered are available in the earlier section from the [#head-e8c6a5396a61d364fdcdd0820f6992db353a8734 desktop-wg discussion] this same week.
To add comments, please click on [wiki:LsbInstall/Comments User Comments] and select Edit or click LsbInstall/Comments?action=edit here to start editing.