Re: FHS filesystem layout issues [was: Re: Request for update and/or release of GDL2 and Renaissance]

[Markus Hitter]

Am 30.01.2014 20:58, schrieb Niels Grewe:

> There’s a well known phrase coined by the philosopher Neil Wilson
> called the ‘principle of charity’. It means that you should always
> assume the most favourable interpretation of another person’s
> behaviour.

OK, let's continue with this philosophers advice.


>>> I think we can sort this out if you can provide us with a list of
>>> things where we deviate from the FHS standard.
> 
> Sorry, I can’t make myself ignore the fact that you don’t provide
> such a list. But maybe I was just being too vague, so let me explain:
> You were talking about lintian

Let's explain to the audience what lintian is: it's a tool which is run
over the just-built packages to identify misalignments with Debian
packaging guidelines. You get warnings or errors like "tool without
manpage", "non-platform dependent resource in platform dependent
package", "static library in non-dev package" and many other things.
There are hundreds of these checks, so if you pass this run, you have a
reasonably good confirmation you align with packaging guidelines.

The reason why I didn't come up with such a list, yet, is threefold:

1. It would be a very long list. Like 30 to 50 bug reports. With just
one hour for properly explaining each, it'd be a weeks worth of work.

2. I fixed or worked around all of them along the process. Most of them
without taking notes.

3. While I found many workarounds, I'm not sure wether the result works.
If I change the installation location of a few files I satisfy lintian,
but would the running end user application still find them?

To get an idea of all these workarounds, please look into the
debian/patches directory. All these patches are applied before
configuring/building for packaging, so each patch can be considered to
be a bug. Most patches are quick fixes, of course, so they need review
and possibly a better solution.

The second source for finding issues is looking into debian/rules, the
packaging makefile. Each line there not starting with dh_... is a manual
tweak, so it's a bug workaround in most cases.

Both, debian/rules and debian/patches come with each source package in
the ...debian.tar.gz file, so there's nothing hidden. debian/rules works
the same way as ordinary makefiles, patches are "diff -u" results. All
easy to understand for developers once you found out which file plays
which role.



>> A _first_ thing would be: GNUSTEP_INSTALLATION_DOMAINS represent a 
>> concept which doesn't exist on FHS systems. There's a concept
>> targetting a similar goal, it's using --prefix at configuration
>> time. For FHS systems, this installation domain thing should go
>> away. For bundle systems, --prefix should go away. For both,
>> domains and prefix shouldn't be mixed.
> 
> Just as with NSBundle, the different domains are part of the
> OpenStep/Cocoa APIs. Why do you think it would be possible to just
> remove them? I don’t see the need to to do that either. What’s nice
> about domains is that they are more like logical locations than paths
> on the filesystem (as prefixes would be).

You see? Yet another defence. Domains _do_not_exist_ in FHS layouts.
Accordingly it's pointless to describe how well and glorious they are.

All you can do is to find some placebo to satisfy the API. Every attempt
to enfoce them anyways just conflicts with the way of thinking
developers used to FHS systems happen to have.

Domains on a bundle layout solve a problem, the problem of finding
system-provided resources (I guess). RedHat, Debian, SuSe & Co. have
different mechanisms to solve the same problem. For example, they run
ld-config after each installation of a library to make sure the runtime
linker finds this new library. They use variables like PATH to make sure
tools are found. They dislike the idea of private resources.

Stupid or not, they happen to think this way.


> * Directories from the system domain are mapped to suitable
> directories below /usr
> * Directories from the local domain are mapped
> to suitable directories below /usr/local
> * Directories from the user
> domain are mapped to suitable directories in /home

Yes, such a mapping is possible (and likely needs to be configurable).
Another reason why the GNUSTEP_INSTALLATION_DOMAIN build variable should
go away. Debian & Co. don't enforce such locations at build time.
Instead they use --prefix at build time and a couple of variables at
runtime.


>> Essentially this means:
>> 
>> - There are only two kinds of (supported) filesystem layouts, FHS
>> and bundle-type. The other ones are obfuscating clutter.
> 
> 1. ‘bundle-type’ is not a filesystem layout.

D'oh. OpenStep and Mac OS X have no filesystem layout? That's news to
me. :-)

> 2. Please try to think a bit strategically here: What will someone
> think who relies on one of the layouts that you classify as
> ‘obfuscating clutter’?

Compare "fhs" and "fhs-system" and you'll see they differ in location
only. So they're the same and the fact they're considered to be
different is what I call clutter. FHS isn't about installation location,
it's an entire (different) strategy to place files and to find them at
runtime.

In other words,

  ./configure --prefix=/usr/local/ --with-layout=fhs-system

is identical to

  ./configure --prefix=/usr/ --with-layout=fhs

Having duplicate ways to do the same thing is redundant and what I call
obfuscation. People have to learn both ways just to find out they give
identical results.

>> - One way to join bundle-type with configure could be to set
>> --prefix according to the choosen domain on bundle-type layouts,
>> ignoring the --prefix given at the command line.
> 
> I must admit that I don’t really understand what you mean with this.
> Could you please explain? Thanks!

GNUSTEP_INSTALLATION_DOMAIN and --prefix conflict. Trying to use both
messes things up. What I tried to show is a way to use a tool made for
FHS layouts (configure) for installing bundle-type/OpenStep/Mac OS X
software. In pseudo-code:

  if [ $layout = "bundle" ]; then
    if [ $domain = "system"]; then
      prefix=/System/
    elif [ $domain = "local" ]; then
      prefix=/
    fi
  else  # $layout = "fhs"
    prefix=$(get_option, "--prefix")
  fi


>> - If you really want to install into unusual places, like
>> packaging, there's always DESTDIR.
> 
> Setting a different DESTDIR for installation should work regardless
> of the layout. If it doesn’t, that’s a bug on its own.

YES! Glad to see we agree in at least one point :-)


> You explicitly mentioned that we
> install bundle resources under lib/, and I think I can understand why
> you don’t want that.

Just a side note: it isn't me who doesn't want that, it's 99% of Linux
developers. Personally, I'd be entirely fine with installing bundles.

> An ad-hoc idea to solve that would be to split
> the bundle and install the loadable object in lib/GNUstep/Bundles/…,
> and the resources in share/GNUstep/Bundles. That would obviously
> require support changes in the NSBundle loading code (which I have
> not looked at as I make this proto-proposal)

Yes, something along these lines should make Linux developers smile. You
could even drop the "GNUstep" part of the path, then, because GNUstep
frameworks and applications would become well behaving FHS citizens.


>> - All this has to be persistent. Once a user installs -make, every 
>> GNUstep thing built with it has to use the same choice of FHS vs.
>> bundle without requiring developer attention.
> 
> If this doesn’t work right now, that would be a bug.

I see we agree on even more.

Bug report. This works (without sourcing GNUstep.sh):

  cd core/base
  ./configure
  make

However, this fails:

  cd core/base
  ./configure
  make -C Tools



> Again, please think more strategically. Not everyone will have a use
> case similar to yours.

Not everybody, but 95% of the open source world. Please don't try to
make Debian packaging a personal preference of mine. These packages
represent roughly 45% of FOSS. Another 45% are RPM packages and I'm
pretty sure they face the very same issues.


Markus


P.S.: I received messages from two independent people notifying me about
SideStep. It's said SideStep removed the FHS conflicts years ago
already, so it's likely a good idea to look at how stuff is solved there.

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.reprap-diy.com/
http://www.jump-ing.de/