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

[Markus Hitter]

Am 31.01.2014 10:29, schrieb Niels Grewe:
>> 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?

For now, because it makes the package build. Actually testing the
result, like building an application with it, is even more work. I'm not
there, yet.


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

Thanks, that's news to me. This is a patch I got from the two year old
packaging in the official Debian packaging sources.

I just disabled this patch and the package still builds, no additional
lintian issues. My first guess is, packaging guidelines don't allow to
install packaged stuff into home directories. These guidelines aren't
debatable, but simply not installing stuff there should align with them,
too.

So I removed the patch, it won't show up in the next package build any
longer. Thanks for pointing this out.


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

Sorry, didn't mean to offend you.

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

Thanks. This confirms doing the mapping is fine and solves the API side.
Accordingly, GNUSTEP_INSTALLATION_DOMAIN has to be removed/disabled when
configuring for a FHS layout, only. Because it's just a convention and
configuration/build tools don't expect it to be enforced by anything but
using --prefix.


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

Are there others than FHS and OpenStep/Cocoa? I'm not aware of them.

make/FilesystemLayout lists 8 files and each of them fits into either
bundle-type or FHS. They differ in installation location, only.

Perhaps it's suitable to keep the bundle-type ones (apple, gnustep,
gnustep-with-network, mac, next), but for FHS, there's only one and
installation location is defined by prefix. The distinction by domain
inside fhs and fhs-system should go away as well.


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

It took me a few hours to build both for comparing them and
understanding the differences. Intitially I tried with fhs and it
wouldn't let me install into /usr/bin, /usr/lib, etc. like every other
piece of autoconf based software does.


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

Here I disagree. --prefix is treated and on top of this, paths are added
from fhs or fhs-system, depending on this "domain". AFAIK, such a
behaviour is unique to GNUstep.

> and gnustep-base imply ignores it

... which means one can't install a -base in /usr and another one in
/usr/local or an arbitrary path like $HOME/sandbox/gnustep? For what I
can see, overriding just one library is a typical strategy for development.

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

Why not simply remove this (for FHS)? Implementing unexpected behaviour,
then implementing even more to return to common standards looks odd to me.


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

It works for me, too.


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

Come on :-) The expected behaviour is that this works, of course.

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

My respect (no pun), you apparently found the issue already. If there's
such a dependency, the makefile should implement it.


Markus

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