[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osdl-lsb-discuss
Subject:    [lsb-discuss] "lsbinstall" redux - how shall we move forward?
From:       "Wichmann, Mats D" <mats.d.wichmann () intel ! com>
Date:       2008-07-18 19:14:38
Message-ID: 3F62CBEE02D6404E98C65934617EB58204BF2325 () fmsmsx414 ! amr ! corp ! intel ! com
[Download RAW message or body]


Quite a while back, a proposal was made for a mechanism to help
software installations to be "good citizens" even when they needed to
perform tasks which were outside the basic "install some files" model.
We dubbed this proposal, since it needed some sort of a name,
"lsbinstall"
although it's worth noting that the topics are not really unique to LSB.
In addition, these issues are really outside of any package manager /
package format discussion, although they certainly are invoked in a
packaging context at times - in some cases, an rpm or deb package would
perform actions in a postinstall or preremove script, but if a tool
were used to perform the abstractions it can just as easily be called
outside that context.

The lsbinstall proposal never really went anywhere in its original form.
An example implementation of some of the topics was supplied, but it
kind of stopped there.  The need for solutions did not go away, though,
and later, the xdg-utils project came along and successfully provided
a mechanism for some of the issues.  The full scope of issues is not
completed, and it's appealing to think about continuing the model to
solve some others.


General Areas of Concern:

1. Namespace Issues

One of the aspects of LSB is guidelines on how to avoid namespace
collisions in the deplyoment of portable software.  As such (and largely
through the import of the FHS specification) it describes directories
that are safe to install into, based on (a) using registered names and
(b) staying out of distribution namespace, which is not subject to
registration requirements, and thus should be considered unpredictable.
In some cases, what should be a system directory *must* be used by
add-on software because the appropriate tool won't find the file
otherwise - consider a file in /etc/cron.daily. In this case, the
LSB describes how to use the namespace protection rules to avoid
problems.

The lsbinstall proposal recognized that there were additional file
heirarchy locations which might have special meanings, but which
were not specified, and perhaps not consistently implemented.  It was
envisioned that the tool could be given the information and install, in
a distro-specific way, the information without the application itself
needing to learn the details of each distribution.  In other words,
an indirection layer for portability, which hides the details.


2. Shared Data Issues

Some system information is stored in a shared file - consider the old
/etc/inetd.conf or the current /etc/services.  (Actually inetd.conf
is an example of a bigger problem:  we know there's some sort of
server-server, and it has some sort of configuration, but there are
several implementations now, how do you add "inetd"-style details?).
Many current packages simply "cat >>" to appent to the end of the
file, which seems a rather inelegant solution.  It has no protection
against collisions and/or multiple definitions, it's not certain
to be safe against changes to the package containing the underlying
file, it doesn't remove cleanly if your package is uninstalled, etc.
The lsbinstall proposal again suggested an indirection layer - a tool
would be called which would, behind the scenes, "make the right thing
happen" and hopefully also allow for uninstalls, etc.  The details of
how that happens would not be part of the LSB, just the mechanism for
calling the command.


3. System Configuration Issues

Some software has a need to record configuration information, for
example values that at least some distros store in /etc/sysctl.conf or
in files in /etc/sysconfig. How can software installations record this
information without having to know the details of how each distribution
handles tuning and other parameters.  Some of you will recall there
was a recent mailing list posting on this topic.

===

The purpose of this message is to remind people of the old proposal
and to try to decide if something should be done about it in the current
release cycle.  What's really needed is a neutral workgroup which
develops
a proposal and a working implementation (like happened with the
xdg-utils
project), it could then go into LSB as a Trial Use standard until widely
deployed, then become full use.  Alternatively, we could decide we can't
make progress on this in this or the next release and to defer or shelve
it entirely.

 
_______________________________________________
lsb-discuss mailing list
lsb-discuss@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
[prev in list] [next in list] [prev in thread] [next in thread]