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

[Niels Grewe]

Am 31.01.2014 um 00:34 schrieb Markus Hitter <mah@jump-ing.de>:

> 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.

Probably they’re not all equally important and not all FHS violations (which is 
what we are talking about here). 

> 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?

How does something count as a workaround if it doesn’t work? 

> 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.

Thanks for the detailed explanation. I have to take a long look at those files. 
From a quick glance, they often don’t include information about the problem 
they are trying to address, which makes it hard to evaluate them. For example 
the no-user-root-paths.patch for gnustep-make breaks installing or finding 
stuff in(to) the user domain. As I read below, you don’t like the domains, but 
that’s no excuse for breaking stuff by packaging. Generally, I must ask you not 
to make changes in packages that cause breakage, because it artificially 
creates a bad impression for the project. You’d probably say that we’re already 
doing a good job at that ourselves ;-). 

>>> 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.

That is an incredibly insulting and completely unfounded statement. I was 
trying to explain the purpose that the domains serve in the OpenStep API and 
why we cannot just remove them. I also explained how to map them to FHS paths 
(which we already do mostly). You even agree with that in a later paragraph. So 
on what account do you make me into a defender of the status quo? Also, reading 
the FHS, the distinction between local and system is clearly present in the 
spec:

> The /usr/local hierarchy is for use by the system administrator when 
> installing software locally. It needs to be safe from being overwritten when 
> the system software is updated.
(4.8.2.1 of FHS 2.3)

It’s just that in FHS, it’s a convention, and in OpenStep/Cocoa/GNUstep, you 
have an API to access stuff in the different domains.


> 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.

What makes you an expert in ‘the way of thinking developers used to FHS 
systems’? (Except for your own) I’m using FHS systems in my day-to-day work, 
and I still have no problem apprehending the idea of differently scoped domains 
for installing stuff. Please stop using this kind of generalisation.

> 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).

That’s what the FilesystemLayout directory is for. Nobody stops you from 
creating your own layout there.

> 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. :-)

Now you have me almost convinced that you’re not trying to have a rational 
discussion but just to troll. You were saying that you want to reduce the 
number of filesystem layouts to two, but you did only explicitly name one of 
them (FHS), and used the catch-all phrase ‘bundle-type’  for all the others. 
This is why I have been asking (you seem to have intentionally left this out, 
it was on the same line as what you quoted above):

> To which [i.e. filesystem layout] are you referring?

Which asks you for information on which of the filesystem layouts in the 
FilesystemLayouts directory of gnustep-make your are referring when you say 
‘bundle-type’ 


>> 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.

Isn’t it a good thing that they produce identical results? Having fhs as the 
default layout is a convenience that allows us to install into /usr/local by 
default. Sorry if this provokes another rant from you, but *here* I don’t see 
the problem.

>>> - 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. 

That does not seem to be true. I’ve looked at the way --prefix is treated by 
gnustep-make and gnustep-base, with the following result: gnustep-make treats 
it correctly, and gnustep-base imply ignores it, so they can’t possibly 
‘conflict’. Of course that’s arguably not the correct behaviour, but it think 
we could fix this by turning GNUSTEP_PREFIX into a variable in the makefile 
that is used to construct the paths (presently, they are constructed at 
configure-time by gnustep-make)

> 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

No, sorry, this still doesn’t make sense to me given my limited mental 
capacity. configure doesn’t install anything. make does that using the rules 
defined by gnustep-make. Wouldn’t it be sufficient if I implemented the 
suggestion stated above? Then you could just set GNUSTEP_PREFIX=@PREFIX@ in 
your GNUmakefile.in and make would respect the prefix when installing.

> 
>>> - 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 :-)

It works for me. Please provide a proper bug report (steps to reproduce, actual 
vs. expected behaviour) and we can sort it out.

> 
>> 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.

Sorry, sloppy expression. What I meant is: ‘You, as a person who claims to 
represent the opinions of an average packager for a FHS-compliant distribution’

>> 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.

I’m not offended if we disagree on this, but I think you mean packagers.

> 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

That’s not a proper bug report: What is the expected behaviour? What is the 
actual behaviour? With what options did you install gnustep-make? Did you run 
make on the Source/ subdirectory before you try to build Tools? That’s 
obviously the dependency and the only way I could make it fail was to not build 
the base library before trying to build the tools, but that’s just expected 
because the tools need to link the library. I tested it both with an in-tree 
build of libgnustep-base and with an installed version of libgnustep-base and a 
cleaned tree.
> 
> 
>> 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.

I’m not trying to make it into a personal opinion of yours. I even explicitly 
acknowledged that it’s worthwhile to improve the filesystem layout so that it’s 
easier to create packages for a FHS-compliant distribution. But you claiming to 
represent ‘95% of the open source world’ is extremely rude to people like David 
or Sebastian how put a lot of effort into creating packages for BSD systems. 
You have to accept that we do not only target FHS-style systems, and that every 
changes we make have to not break those systems or make it unnecessarily hard 
from them to create packages (after all, you’re demanding the same for 
FHS-compliants systems, so it should mutatis mutandis hold for the other 
installation styles as well). Saying stuff like that hurts you, because it 
makes people think that you’re just trying to pick a fight instead of working 
towards improving the situation.

Regards,

Niels