Re: Namespace Management in GNOME

[Brian Cameron <Brian Cameron Sun COM>]

Kalle/Vincent/Larry/Dan:

I'll respond to all of your emails in one.

Kalle Vahlman said:
> Lots of programs included in GNOME come from "the outside", so they
> have high probability to have a non-gnome related and often
> well-established name (if you don't count names which start with a 'g
> gnome-related', then it's all programs).

Right.  It's probably not possible to change the names of many programs
that are currently in the GNOME stack, but it might be useful to have
a specification which highlights what the naming convention for future
components should look like.  Though putting together a specification
might highlight a handful of existing programs or libraries that could
have better names.

> Should these then change their name as a requirement for inclusion?

If we put together a specification, I think it would be reasonable
to expect that programs meet the requirements of the specification when
they are added to GNOME.  Though, I think having a standard naming
convention for files in /bin is less important than having a clear
specification for filenames that are user-integration points.

Vincent Untz said:
> Having a document that specifies this would be really useful. E.g. the
> panel used to install files in /usr/share/gnome/panel
> and /usr/share/gnome-panel/glade which is kinda... weird.

Thanks.

Larry Virden said:
> A related issue, in my mind, is the files installed in the user's
> /home directory.
> [...]
> Why can't all of this be put under a single directory?

Good point.  I think it would be good to put together is a GEP that
highlights not just the most appropriate file-install locations for
directories like datadir, sysconfigdir, etc., but also the best
file locations for use in the user's $HOME directory.

Dan Winship said:
> On Thu, 2004-12-02 at 15:18 -0600, Brian Cameron wrote:
>
> > 1) Data is stored in directories with names that are too generic
> > 2) Furthermore, GNOME clutters the /usr/share directory
> > 4) Files aren't always installed to the most sane location.  For
> >    example, there are a number of programs that GNOME currently
> >    installs to /bin that should probably be in /libexec
>
> Different OSes/distros are going to have different conventions here
> though. Most Linux distros seem to embrace the per-package "clutter"
> in /usr/share rather than trying to avoid it. (I have directories owned
> by 85 different packages in my /usr/share right now.)

Right.  But just because many users do not mind clutter in their
/usr/share directory does not mean that it isn't a good idea for GNOME
to be a better citizen than the average.  Aside from keeping such
directories better organized, the use of sane directory naming
conventions should highlight to the end user where integration points
are located.  Ideally it should be clear where to integrate files
simply by the location on the file system.  Right now, GNOME installs
files to /usr/share in a way that is not at all clear which subdirectories
might be user-integration points and which are private/internal data
for applications.

> Likewise, many
> (most?) Linux distros don't use libexec at all (which contributes
> heavily to GNOME hackers forgetting to use it where appropriate).

Right.  Sun is an example of such a company.  Sun installs libexec
programs just to lib.  Regardless of where libexec files are installed,
it is nice to be able to specify that they not clutter up the /bin
directory.  Most GNOME modules support this.  I suspect most of the
problems are oversights/bugs that can be easily corrected once
identified.  I'm just highlighting some of the Namespace Management
issues that would be nice to see improved in the GNOME stack.

> OTOH, Sun isn't the only OS that doesn't like the default locations some
> of the packages use. Most of the patches against GNOME packages in the
> NetBSD packages collection these days are to tweak things like
> documentation and config file install locations.
>
> Maybe what we need is just a better set of directory-specifying flags
> for configure, and mandate consistent handling of those flags across all
> GNOME packages.

Yes, this is a good idea.  Better configuration options are desirable.
Sun does the same thing and patches GNOME to change file install
locations.  Perhaps if you shared more detail about the sorts of
patches that NetBSD uses to change file-locations we could
ensure that the specification highlights that modules in the
GNOME stack should support certain configuration options to allow
distros more freedom in specifying file install locations.

However, I think the more important issue is to separate files that
are user-integration points from files that are private application
data.  Eliminating unnecessary filesystem clutter is also desirable.

At any rate, it seems that there is some interest in putting together
a specification - unless I hear that somebody has an objection.

So I'll spend the next few days putting together a GEP that explains
how GNOME is currently installing files to the file system and a
proposal of how we could better organize them.  Then we can discuss
the details.  I'm sure I won't get it right with a first draft, and
discussion will certainly be necessary to work out all the details.

Even if the end result is that we decide not to change anything,
such a GEP would probably be useful - since it would explain how
GNOME is currently making use of the filesystem.  That way there
would be at least a roadmap to understand the clutter.

As GNOME evolves, such a document could continue to be useful if
it is updated as modules decide to change the way they interact
with the filesystem, or as modules are added/removed.  I'd be happy
to maintain such a document since I have to anyway for ARC.
Though I'm certainly hoping that the community would find such
documentation useful enough to assist me in identifying when
things are changing.

--

Brian