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

[Niels Grewe]

Am 30.01.2014 um 18:25 schrieb Markus Hitter <mah@jump-ing.de>:

> Am 30.01.2014 15:42, schrieb Niels Grewe:
> 
>> 1. I don’t understand why you are not reporting these problems to the
>> list or the bug tracker.
> 
> A couple of reasons:
> 
> - Looking at this -make documentation failure bug report, the very first
> answer from a developer was to close the bug. Later it was refused to
> reopen it. Intially the defending statement was "read the
> documentation", later it was exactly the opposite, "things should just
> work". All done with a refusal to execute the provided commands and
> extreme amounts of argumentation for such a simple issue. The patch
> eventually applied had only fragments of the provided patch, notably, it
> kept dead code and added useless ("nice to have") stuff. Together, one
> could describe this as "fight the bug reporter at all costs". The time
> spent into such an adventure is undoubtly invested much better in
> writing code.
> 
> - I've talked to many people by email, IRC, here, watched other
> conversations. There's barely an acceptance problems actually exist.
> Instead people try very very hard to find reasons for avoiding changes.
> How can a piece of software evolve if the very first goal is to not
> change it?

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. In this spirit, I’d 
like you to consider that maybe people are not trying to be difficult on 
purpose. Maybe they just didn’t understand what you were trying to tell them. 
At least it was this way with the make documentation issue for me: I 
wholeheartedly admit that it took a few days before it dawned to me what the 
bug report was trying to say (Note I’m not saying that that’s your fault, 
sometimes I’m just slow on uptake or not diligent enough while reading). In 
such cases, anything but a polite re-explanation just furthers misunderstanding 
and hostility, which doesn’t help anybody. (I also apologise if this sounds 
patronising, but I just want to make sure that you know on what basis I’d like 
to discuss this) 

> 
>> So I can only hope that these are the right
>> ones:
>> 
>> http://bazaar.launchpad.net/~thopiekar/gnustep/gnustep-make-packaging/files
> 
> This is the work of Thomas. He went the trivial way and installs with
> the bundle layout, ignoring documentation, lintian issues and Debian
> packaging guidelines. The advantage of this approach: no build issues
> and likely working GNUstep applications. Disadvantage: not acceptable
> for debian packagers, so no appearance in official package sources.
> 
> You had the links to an debian guidelines compliant approach already,
> even quoted them. Let me quote the quote:
> 
>>> The result is here:
>>> 
>>> (first attempt)
>>> https://launchpad.net/~mah-jump-ing/+archive/ppa/+packages
>>> 
>>> (second try)
>>> https://launchpad.net/~gnustep-dev/+archive/weekly/+packages
>>> 
>>> First try results in something not working not well enough to build an
>>> application. Second try with very vague results. More than a dozen
>>> patches required, bundle-style stuff ripped apart to align with FHS
>>> demands. Still pictures in /usr/lib, where they don't belong by FHS
>>> standards. This isn't packaging, but porting.
> 
> If you want to see the code used for packaging, click on "View package
> details, open the package you're interested in, then download the
> ...debian.tar.gz file. Sources are there, too, in the ...orig.tar.gz
> file. They should match SVN sources of the same day, plusminus a few
> commits.

I invoke the principle of charity again: Sorry, I didn’t purposefully ignore 
what you wrote, I just didn’t know where to look. One of our problems here 
seems to be that you assume that your audience is competent with how launchpad 
or debian packaging works. I really admit that I’m not, and it would have saved 
me quite a few minutes of my tea break if you had included this information in 
your earlier email. On the other hand, I realise that the same might apply with 
regards to the stuff I try to tell you, so I will try to be more clear in the 
future and I would kindly ask you to enquire for a clarification whenever you 
have the feeling that I’m not being clear enough.

> The BIG question with all this is: can you actually build and run an
> application on top of this?
> 
> 
>> 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, so I assumed that you have some output form that tool which identifies 
what installation locations it regards as incompatible with FHS. Is that not 
the case? Ideally I’d like to know which files violate which paragraph of the 
FHS, so I can start thinking about how we can become compliant with those 
paragraphs.

> 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). 
Having said that, they still can be mapped nicely to directories within the FHS 
space (with the exception of the network domain):

* 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 
(the xdg basedir specification can give some hints on this, but it doesn’t 
provide a complete solution, my feeling is that most stuff would live below 
/home/${username}/.local/ )

So basically, packaged GNUstep stuff is installed into the system domain, 
shared self-compiled stuff goes into the local domain, and if you are building 
things just for yourself, you install them into the user domain.

> 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. To which are you referring?

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’? If you 
want your arguments to be heard, please try to be a bit more civil with regards 
to usage scenarios that don’t apply to you (they might be extremely important 
to someone else). I’ll just assume you mean ‘The priority should be to support 
the FHS layout and one “bundle-type” layout in a sensible way’. (And as I said, 
I would add the phrase ‘without breaking things for everyone else’) Can you 
agree with that?

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

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

> - There's a good chance this requires ObjC code changes to deal with the
> non-existence of domains on FHS systems.

I’ve already made my case for why domains are not going away, so I’ll assume 
that you don't mean something radical like throwing out NSPathUtitlities. I 
already mentioned that in my last email that some code changes might be 
required. You explicitly mentioned that we install bundle resources under lib/, 
and I think I can understand why you don’t want that. 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), which we’d need to discuss and 
make sure that they doesn’t break other layouts, but it still might be worth 
doing if it drastically increases the time it takes to get new GNUstep releases 
into distributions like Debian or Ubuntu.

> - Lots of code changes in the build scripts/makefiles, of course.

You make it sound worse than it is. All those changes would be localised in 
gnustep-make. If we can improve things there, everything that uses it will 
automatically benefit from improved ease of packaging for FHS compliant 
distributions.

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

> 
> Good luck with explaining such changes to people who still search for
> gcc 2.95 support.

Again, please think more strategically. Not everyone will have a use case 
similar to yours. Also, I’m hard pressed to think of any reason what compiler 
versions would have to do with filesystem layouts, so you’re probably just 
being sarcastic. You shouldn’t be if you want to see your issues resolved, 
since it steers people away from regarding your arguments impartially. 

Okay. That was a long one. I think the gist of it is: I’m willing to work 
constructively with you to resolve the problems you have, but I need a clear 
problem statement and some understanding for the fact that there is a wide 
variety of people that GNUstep caters for.

Kind regards,

Niels