GNOME Community:
A while back I mentioned that I would put together a proposal about
how GNOME could better handle namespace management with regards to
file installation locations. I got sidetracked for a bit because
ARC made it a necessary requirement to document the current state
of affairs for our upcoming GNOME 2.6 release. So I've put
together the attached document which highlights where GNOME is
installing things in the 2.6 timeframe. I wanted to share this
document with the community for a couple of reasons:
+ I am hoping people in the community would be willing to review
the document and let me know if I've captured all the useful
information.
+ Although this document is somewhat Sun-centric, my plans are to
modify it so it is more generic and applies to the community
development at CVS head. I think having a document that clearly
highlights where GNOME installs things would be of general
interest to people developing GNOME and to people who want to
integrate applications into GNOME.
To properly understand this document, I think it is necessary for
me to spent a little time explaining Sun's ARC (Architecture Review
Committee) process and the terminology used in ARC documents. Sun's
Solaris operating system comes with a committment that applications
will not break without notification when a user upgrades from one
version of the operating system to the next. In other words, if
something is going to break or disappear in Solaris, Sun is
supposed to give users a one-year prior heads-up notification. Now
that Sun is shipping GNOME as a part of Solaris, these sort of
rules apply to Sun's delivery of GNOME.
The way that Sun tries to ensure that a component of Solaris
remains stable is via the ARC process. The ARC requires
that the Sun GNOME project team provides a complete list of all
interfaces (functions, data structures, enumerations, environment
variables, file locations) that have changed from release-to-release
so that they can verify that interfaces are not changing in ways
that are incompatible. ARC labels interfaces with the following
stability levels which indicate the degree of support that Sun
provides to users:
+ Standard - An interface that follows a well-accepted standard,
such as the standards from w3c.
+ Stable - An interface that customers can depend upon. To be
Stable an interface must follow a specification or
the maintainers must have made an explicit guarantee
that the interface is one that can be depended upon.
+ External - A stable interface that we believe customers can
depend upon that is provided by an external body
(such as GNOME) but is lacking a formal specification
or an explicit guarantee of stability.
+ Unstable - An interface that is for public use, but not
guaranteed to work from release-to-release. People
making use of such interfaces accept breakage if/when
it happens.
+ Private - An interface that is for the private use of the
project, not intended for public use. User changes
to private interfaces are not supported. Sun uses
a variety of subclasses of "Private" to highlight
Private interfaces that are Private to a module,
to a group of modules, or to a group of projects.
+ Obsolete - An interface that has been deprecated
+ Unsupported - An interface that is not private, but is also not
supported. For example, a demo program that is
shipped with a project as an example of how to use
an interface.
By listing these out, I am not trying to suggest that the GNOME
community should use the same terminology. I describe the
interface taxonomy that Sun uses only so that you can properly
understand ARC documents that are shared with you, such as the
attachment.
As you might imagine, going through the entire GNOME stack and
trying to put each of its interfaces into the above buckets has
been a time-consuming and painful process for us here at Sun.
This is partly because the community does not really have a process
for documenting change in a consistant way. I'd certainly be
interested in exploring ways to improve the situation by making
the public documentation more complete, for example, making it
unncessary to do so much internal documentation. Or to improve
the way that the community goes about interface change
notification.
Since Sun is already making efforts to provide such change
management documentation anyway, we have been thinking it would
be more useful if we were instead to work more closely with the
GNOME community and work towards providing more public
documentation rather than internal-to-Sun documentation.
Much of the information that Sun's ARC requires is really of
general use, so it seems to make more sense to maintain such
information publically so everyone can make use of it. If we
were able to enhance developer.gnome.org so that this sort of
information is documented publically, the odds that maintainers
in the GNOME community might take an interest in keeping docs
up-to-date, and to review changes would obviously be much more
likely. It would also make ARC more comfortable with GNOME if
they could see that the GNOME community shares some of its concerns
and is interested in improving areas that it identifies as being
troublesome.
At the last GUADEC I talked with a number of people in the GNOME
community about the idea of Sun's ARC working more closely with
the GNOME community, and it seemed that the general response was
positive. Obviously a "closer" relationship does not mean that
Sun's ARC would be in a position to dictate anything to the
community. Instead, I think a healthy closer relationship would
be one where the GNOME community could take advantage of the
change management documentation that Sun needs to put together
anyway and better mechanisms for communicating and resolving
issues that ARC identifies. It might also be useful for the
GNOME community to make use of ARC resources to assist in
reviewing proposals and standards, such as ones proposed to
freedesktop.org.
I've been working with the ARC chairs for the past several months
about the idea of making ARC work better with external communities
like GNOME and it seems that a number of high-level people within
ARC are interested in getting more involved with the GNOME project.
It isn't quite clear how we can make most effective use of such
resources or how to create the best synergy, but to get the ball
rolling I would like to take one of the issues that ARC thinks is
a problem and hopefully work with the GNOME community to make
improvements in this area. If this works out well, I think ARC
will be encouraged to work more closely with other areas of GNOME
as well.
As I've mentioned in a previous email, one significant issue is
namespace management within the file system. The attachment tries
to highlight all the files that GNOME 2.6 installs to the /usr/share,
/var, /etc, and $HOME directories and place them into the ARC
interface stability buckets described above. You'll notice some
interfaces are described as "External" or "Stable" indicating the
interfaces which users may need to integrate with that they should
be able to depend upon from release-to-release. Other interfaces are
described as "Private" which indicates that these are directories/files
that are only used by particular GNOME applications and user's should
not really mess with them (or expect changes to them to work from
release-to-release).
I would very much appreciate it if people from the GNOME community
could review this document for completeness and to verify that I've
made sane choices about what is "Stable/External" and what is "Private".
I suspect Sun's understanding of what is "Stable/External" is
probably conservative and would be interested in finding out if
the community has a less conservative perspective. You can respond
to me privately to avoid needless traffic on the public mail alias
and I will send an updated document for further review after I've
collected comments and made appropriate changes to the document.
As I promised in my previous mails, my goal is to put together a
proposal that will suggest ways that we could better standardize the
way GNOME installs files to the filesystem. As an experiment, I
would like to put this together in GEP-proposal form and have ARC
and the GNOME community review it in parallel with comments from
both communities cross-posted so that ARC and the community can
together discuss this topic. Joe Kowalski, who is a senior ARC
member, has agreed to be the ARC case owner and to make the needed
changes in the ARC process to allow this to happen. Joe has
informed me that it will likely be early January before the internal
processes can be set-up here at Sun to make this possible, so I plan
to submit the proposal to both communities at that time.
I think this is a good area to start with for a number of reasons:
+ Currently GNOME seems to be installing an excessive number of
files to directories like /usr/share. For example, n Solaris
/usr/share contains only 6 directories (audio, dat, ipfilter,
lib, locale, and man). After installing JDS (including GNOME,
StarOffice and a few Java applications) that number goes up to
101 files and subdirectories, 79 of which belong to GNOME. It
certainly seems that GNOME could be better about avoiding
clutter in common directories such as /usr/share.
+ Organizing directories like /usr/share, /var, /etc, and $HOME
is something that is easily grokked by people, so this is a
topic that the GNOME community can explore easily. It isn't
an issue that requires deep knowledge of a particular GNOME
application to resolve.
+ Making patches to better organize the way GNOME interacts with
the filesystem is fairly straightforward, so this might be a
good opportunity for GNOME love. Working to resolve this sort
of issue provides an opportunity to bring in new developers
and provide some straightforward work that can be easily
deligated.
My hope in sharing this document is that it will generate some
discussion about ways that the GNOME community could better
organize the files it installs to the filesystem. This will
also help me in putting together a proposal that will reflect the
ideas and concerns of the GNOME community.
If this is successful, I know that Sun's ARC would be interested
in also working towards improving the stability of other GNOME
interfaces. I know another area that they would like to see
better documented is the namespace management used within Gconf
key/value pairs. I suspect such documentation would also be
publically useful. But first lets see how this goes.
I've cc:ed the sun-sac-foss-ext sun com alias which is used by
ARC people within Sun to keep in touch with relevant discussion
going on in the external FOSS community.
--
Brian
Title: PSARC/2004/XXX GNOME 2.x File Locations on Solaris
GNOME 2.x File Locations on Solaris
BACKGROUNDThis project changes the original file location policies as defined by PSARC/2002/708 and updates the file location information so it corresponds to the GNOME 2.6 minor release. Indeed, the respect the GNOME community gives to binary compatibility was a major reason that GNOME was selected over other desktops such as KDE. It is believed that Sun can support GNOME as an Evolving interface while also maintaining compatibility with the community version. It is critical that GNOME be managed consistently on both Sun Linux and Solaris. One aspect of a consistent GNOME management experience across both platforms is the file hierarchy. Administrators should be able to go to the same place on each platform and find the same things in the same places. A secondary requirement is that Sun's GNOME be consistent with other Linux distributions. Although inconsistent at other levels of the file hierarchy, most major Linux distributions tend to put GNOME directly into /usr/lib, /usr/bin, etc. Indeed, they are prohibited from creating a /usr/gnome directory by the Filesystem Hierarchy Standard (FHS) [3]. The intention of the Sun GNOME project team is to move to more stable interface classifications with each future release. The GNOME team is currently working with the community with the hope of improving the stability of file installation locations. Historically the community has placed more of a priortity on library interface stability, so working with the community to improve the interface stability of file locations will hopefully improve with more Sun involvement with the GNOME community The original proposal in LSARC/2002/201 (used with GNOME 2.0) was as follows:
[*] bin, lib, share, man This set of locations is consistent with the file location policy for integrating External components into Solaris as established by PSARC/2000/488 - Solaris/Linux Commands Compatibility. Using the above policy, with each new release of GNOME, when interfaces would be changed to become more stable, their location would also change, probably with compatibility links in there former location. To make GNOME more consistant between the Sun and Linux platforms, it has been decided to no longer use the /usr/gnome, /etc/gnome, and /var/gnome for private application data. Instead all GNOME files will be installed to the default location to ensure consistancy between Sun's Linux and Solaris operating systems. Instead of trying to reorganize such files after-the-fact, Sun will work with the community to improve the organization of files so that stable and private file interfaces are better organized for all GNOME distributions. This will better serve Sun since experience with GNOME 2.0 has shown that maintaining patches to modify file installation locations is time-consuming and bug-prone. PROPOSALIf Sun Linux is LSB Certified [2], then it would also be required to follow the Filesystem Hierarchy Standard (FHS) [3]. FHS is part of the LSB certification specification. RedHat, for example, states that it follows the FHS [4]. The FHS states: "Large software packages must not use a direct sub directory under the /usr hierarchy." This requirements precludes a special directory for GNOME on Sun Linux. Sun will work more closely with the community to ensure that GNOME more closely follows the spirit of the LSB. A simple GUI tool, gnome-about, will provide a description of the current stability level of GNOME. This tool is either activated from the command line or the GNOME panel menu. Additionally, as long as a significant portion of GNOME remains External, a pop-up will be displayed at first use (per user) briefly explaining the commitment level and providing textual references to where more details can be found. This is captured in bugid 4729461. ISSUESThis proposal goes against the file location policy outlined by PSARC/2000/488 - Solaris/Linux Commands Compatibility. This project assumes that the benefits of consistency with future releases of Solaris and across multiple operating systems outweigh absolute adherence to this policy. A precedence for installing components that are initially External, but intend to move to more stable interface classifications in the near future, has already been established by PSARC/2001/586 - dig(1m): Domain Information Groper. TARGET RELEASEMinor and patch release of Solaris.
INTERFACE TABLE
All interfaces are directories, except those marked with [#].
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[1] |
Refer to the References section “R1 Related Projects” of LSARC 2004/713 (Cinnabar Heavy) for references to other cases which relate to GNOME 2.0 and 2.6. |
|
|
|
|
|
|
|
[2] |
http://www.opengroup.org/lsb/cert/cert_prodst.tpl |
|
|
|
|
[3] |
http://www.pathname.com/fhs/ |
|
|
|
|
[4] |
http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-filesystem-fhs.html |
|
|