Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac

[Richard Frith-Macdonald]

On 16 Sep 2010, at 13:26, David Chisnall wrote:

> On 16 Sep 2010, at 12:37, Richard Frith-Macdonald wrote:
> 
>> On 12 Sep 2010, at 21:16, Riccardo Mottola wrote:
>>> I'm absolutely against having FHS as a default. It is against the 
>>> OpenStep/Cocoa philosophy! The best layout is the GNUstep layout with 
>>> prefix=/ in my opinion, although using /usr/GNUstep is sensible because it 
>>> is not such a great "clash" in a mixed environment.
> 
> I also prefer this, but it's worth noting that a lot of systems use a small / 
> partition and a larger /usr or /usr/local.  I generally install in 
> /usr/local/GNUstep and then symlink stuff to /.  
> 
> I think it's also important to do this if we are trying to attract developers 
> familiar from Cocoa - give them the FS layout that they are familiar with.

Sure ... they can use the 'apple' layout.

Incidentally, it's perhaps a subtle distinction, but I've no desire to make FHS 
the default layout, what I want is to make the native filesystem layout default.
The important thing is that things should just work for the naive user who 
installs from source ... the loader should find their shared libraries, their 
'man' command should find the manual pages, their shell should find the 
executables etc.

>> Are you against it in every situation?
>> The reason I ask is that there are a few different cases to consider ...
>> 
>> 1. Hopefully, increasingly,  people will be installing packages provided by 
>> their operating system distribution ... in which case the person who manages 
>> that package controls the filesystem layout, and the default in gnustep-make 
>> is irrelevant since it's not used.  I expect this is the largest group of 
>> users already.
> 
> Most packagers don't bother with optional configuration, so the default means 
> that is what they will see.  The FreeBSD packages, for example, use the 
> GNUstep layout because it's the default.  As, I believe, do the Arch and 
> Gentoo ones.  The Debian ones use FHS because they have a policy of using FHS 
> for everything even when it doesn't make sense.  
> 
> This is especially true of something like GNUstep.  For something like GNOME, 
> there are probably lots of people interested in packaging it for a given OS.  
> FreeBSD has over 100 GNUstep-related packages maintained by a single person 
> (thanks Dirk!), so expecting him to manually tweak the configuration of any 
> of them is probably not feasible.  
> 
> By and large, packagers want to automate the packaging job as much as 
> possible, and that means having defaults that Just Work™

Well then, the packagers come close to being in my category (4) then ... 
GNUstep should have a native setup for them so that the packages they produce 
will just work for the end users.
Actually, I don't think that's ideal either ... we should assist packagers to 
produce better packages ... and contribute filesystem layout configurations for 
their systems to gnustep-make, and contribute installation scripts to the 
packages.
It's not good for GNUstep if packagers produce packages which install and then 
don't work.

>> 2. Similarly, there may be alternative packages provides ... eg a complete 
>> GNUstep desktop package ... which would again use the layout the package 
>> manager decides to use ... so the gnustep-make default is not used.
> 
> These are usually metapackages, so this is just a case of (1) being installed 
> as a dependency.

That's not really what I meant ... I was thinking of alternative/unofficial 
distributions of GNUstep.  eg. if Riccardo wanted to produce a whole GNUstep 
environment to be installed on top of an Ubuntu system *instead* of the 
packages which come with Ubuntu ... he might want to do that because he hates 
the Debian insistence on FHS and would like Ubuntu users to have a whole 
integrated system using an apple layout.

>> 3. Experienced developers and users who habitually build from source will 
>> set whatever layout they like (and may even have more than one layout), and 
>> as long as my changes work properly, once they have set a preference it's 
>> recorded in their GNUstep.conf file so that the setting is retained when 
>> they update gnustep-make.  So again, the default is not used (though 
>> obviously the first time they encounter the change these people will need to 
>> set their preference to avoid using the default). 
> 
> Well, I probably think I am a reasonably experienced developer, and I wasted 
> half an hour after this change working out why my changes to -base didn't 
> seem to be being picked up by running applications.  I then had to look in 
> the documentation and, eventually, worked out how to change -make back to 
> behaving as I expected.

Teething troubles ... ideally we should pick up existing system setup and use 
it, so that should not be an issue.

>> 4. An inexperienced developer installing from source ... this is the person 
>> who gets the default behavior.
> 
> Agreed.
> 
>> I hope I haven't missed a group ... obviously my aim is to target the people 
>> in the last group ... someone who is trying GNUstep for the first time and 
>> for whom we want the code to just work with the default configuration.
>> Do you think that it's more important for these people to have stuff 
>> installed in a GNUstep file hierarchy than to have programs run and example 
>> code build?
> 
> I don't see a conflict between the two.  LanguageKit loads frameworks using 
> NSBundle so that you can distribute a portable .app bundle with the source 
> code in the bundle and a plist describing the frameworks that it needs.  It 
> loads the frameworks, JIT-compiles the code, and then runs the app.  
> Apparently this doesn't work with the FHS layout, so Étoilé doesn't support 
> systems that use the FHS layout.

1. If Etoile doesn't work then it would be good to know why ... I guess it's an 
Etoile bug, but it might be a bug in the GNUstep core.
2. The conflict is that nothing works with a non-native filesystem layout 
*until* you have sourced GNUstep.sh or something similar.

>> If not, do you have a suggestion for a better way to improve the chances of 
>> GNUstep working for this fourth group.
> 
> Maybe by adding this to the end of -make's install?
> 
> echo source ${GNUSTEP_MAKEFILES}/GNUstep.sh >> /etc/profile
> echo source ${GNUSTEP_MAKEFILES}/GNUstep.csh >> /etc/csh.cshrc

Sure, we've discussed that kind of thing before and there was a strong argument 
that editing such files is intrusive, and system dependent since the 
appropriate files vary, and generally somewhat complex (you need to remove old 
edits before making a new one) and error-prone.  I'm sure we could do it, but 
using native conventions seems simpler so far.

>> One more thing to point out ... from the emails we occasionally get on the 
>> mailing list, it's clear that people in this fourth group exist and try 
>> GNUstep repeatedly until they either give up in disgust, read enough to sort 
>> things out themselves, or occasionally mail the rest of us for help.  My 
>> expectation is that the ones who give up will be telling other people and 
>> giving GNUstep a bad reputation ... I'd like to avoid that.
> 
> Even a message at the end of installing -make telling users that they have to 
> add this line to their .profile would help people compiling from source.

Yes, I'm all for that, but I think there are plenty of people who just wouldn't 
read/notice it :-(

> It's worth noting that the last person we had on the list with this problem 
> was using Windows.  Changing the default FS layout in -make does absolutely 
> nothing to help Windows users.

I think on windows we already set the filesystem layout and set everything up 
for the user in the package installer.  IIRC the problem there was they were 
not using the msys shell provided in the GNUstep package so things were totally 
broken for them.  I'm not sure what we can do about that.