GNUSTEP_INSTALLATION_DOMAIN
I'd like to propose a new option for gnustep-make ... GNUSTEP_INSTALLATION_DOMAIN which could take the values SYSTEM / LOCAL / NETWORK / USER. This option can only be set on the command line, or before including common.make ... but using it in GNUmakefiles should be discouraged as all packages should install by default in the default locations ... except for maybe gnustep-base :-) The meaning of the option is obvious ... it would determine if we install into System/Local/Network/User (currently you use GNUSTEP_INSTALLATION_DIR for this). The advantage of this option is that it could work with the Unix (or generally 'native') filesystem support ... eg, on GNU/Linux, make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM would install stuff in /usr, while make GNUSTEP_INSTALLATION_DOMAIN=LOCAL would install stuff in /usr/local. We'd still keep GNUSTEP_INSTALLATION_DIR, but only in the situations that used to work (ie, GNUstep or Apple filesystem layout), and it would be discouraged to set GNUSTEP_INSTALLATION_DIR inside GNUmakefiles themselves. In general, GNUSTEP_INSTALLATION_DIR doesn't work well with the more flexible directory layout. Most of the times you want to set GNUSTEP_INSTALLATION_DIR to GNUSTEP_SYSTEM_ROOT, for example, but that variable is no longer defined until later inside the GNUmakefiles (you're no longer supposed to have sourced GNUstep.sh!), and moreover, it might not even have much sense if the filesystem is not the GNUstep one. GNUSTEP_INSTALLATION_DOMAIN would let you do the same things, but could be made to work in more general contexts. :-) Comments welcome Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: GNUSTEP_INSTALLATION_DOMAIN
> This option can only be set on the command line, or before including > common.make ... > but using it in GNUmakefiles should be discouraged as all packages should > install by default in the default locations ... except for maybe gnustep-base :-) Thinking about it, I wouldn't want even gnustep-base to set it. If I'm testing the Unix filesystem layout, I wouldn't want gnustep-base to install stuff in /usr ... ;-) It should be installed in /usr/local (or wherever we decide the local stuff goes) unless I explicitly require it to go in /usr. ;-) Comments ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 9 Oct 2006, at 16:17, Nicola Pero wrote: I'd like to propose a new option for gnustep-make ... GNUSTEP_INSTALLATION_DOMAIN which could take the values SYSTEM / LOCAL / NETWORK / USER. This option can only be set on the command line, or before including common.make ... but using it in GNUmakefiles should be discouraged as all packages should install by default in the default locations ... except for maybe gnustep-base :-) How would the default locations be defined ... I don't think we want the default location for the stuff currently installed in /usr/ GNUstep/System or /usr/GNUstep/Local to suddenly be ~/GNUstep The meaning of the option is obvious ... it would determine if we install into System/Local/Network/User (currently you use GNUSTEP_INSTALLATION_DIR for this). The advantage of this option is that it could work with the Unix (or generally 'native') filesystem support ... eg, on GNU/Linux, make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM would install stuff in /usr, while make GNUSTEP_INSTALLATION_DOMAIN=LOCAL would install stuff in /usr/local. How would that behavior be defined ... eg how do we specify whether the SYSTEM domain is /usr rather than /usr/GNUstep/System? Simply by a configure-time option to gnustep-make to define the filesystem layout make is to use? We'd still keep GNUSTEP_INSTALLATION_DIR, but only in the situations that used to work (ie, GNUstep or Apple filesystem layout), and it would be discouraged to set GNUSTEP_INSTALLATION_DIR inside GNUmakefiles themselves. In general, GNUSTEP_INSTALLATION_DIR doesn't work well with the more flexible directory layout. Most of the times you want to set GNUSTEP_INSTALLATION_DIR to GNUSTEP_SYSTEM_ROOT, for example, but that variable is no longer defined until later inside the GNUmakefiles (you're no longer supposed to have sourced GNUstep.sh!), and moreover, it might not even have much sense if the filesystem is not the GNUstep one. GNUSTEP_INSTALLATION_DOMAIN would let you do the same things, but could be made to work in more general contexts. :-) I'm not sure I understand ... Your examples are setting the domain from the command line, but I would have thought that doing it inside the makefile would be common. That is to say, most packages would want to be installed in the LOCAL domain, core packages in the SYSTEM domain, and new code that users par developing would probably want to be in the USER domain by default ... but you wouldn't want to have to remember to set a command-line option to control that every time you typed 'make'. Is the idea that makefiles would contain code to set the domain if it had not already been set at the command line? eg in the base library makefile something like ifeq ($(GNUSTEP_INSTALLATION_DOMAIN),) GNUSTEP_INSTALLATION_DOMAIN=SYSTEM endif or perhaps GNUSTEP_DEFAULT_INSTALLATION_DOMAIN=SYSTEM ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Hi Nicola, Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] And then GNUSTEP_INSTALLATION_DIR decides where the root is, maybe it should be called GNUSTEP_FS_ROOT, like in GNUSTEP_FS_ROOT=[/usr/GNUstep/System|/usr/GNUstep/Local|/usr|/usr/local|/opt] I understand the use of domains, since it abstracts the filesystem from the user, but there is no NETWORK equivalent for FHS and WINDOWS, and some systems like to use /opt, which you rule out. And what does SYSTEM mean on a Unix but non-FHS system, does that mean /usr or /, or /opt? Just my 2 cents. Dennis Leeuw Nicola Pero wrote: I'd like to propose a new option for gnustep-make ... GNUSTEP_INSTALLATION_DOMAIN which could take the values SYSTEM / LOCAL / NETWORK / USER. This option can only be set on the command line, or before including common.make ... but using it in GNUmakefiles should be discouraged as all packages should install by default in the default locations ... except for maybe gnustep-base :-) The meaning of the option is obvious ... it would determine if we install into System/Local/Network/User (currently you use GNUSTEP_INSTALLATION_DIR for this). The advantage of this option is that it could work with the Unix (or generally 'native') filesystem support ... eg, on GNU/Linux, make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM would install stuff in /usr, while make GNUSTEP_INSTALLATION_DOMAIN=LOCAL would install stuff in /usr/local. We'd still keep GNUSTEP_INSTALLATION_DIR, but only in the situations that used to work (ie, GNUstep or Apple filesystem layout), and it would be discouraged to set GNUSTEP_INSTALLATION_DIR inside GNUmakefiles themselves. In general, GNUSTEP_INSTALLATION_DIR doesn't work well with the more flexible directory layout. Most of the times you want to set GNUSTEP_INSTALLATION_DIR to GNUSTEP_SYSTEM_ROOT, for example, but that variable is no longer defined until later inside the GNUmakefiles (you're no longer supposed to have sourced GNUstep.sh!), and moreover, it might not even have much sense if the filesystem is not the GNUstep one. GNUSTEP_INSTALLATION_DOMAIN would let you do the same things, but could be made to work in more general contexts. :-) Comments welcome Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
> How would the default locations be defined ... I don't think we want > the default location for the stuff currently installed in /usr/ > GNUstep/System or /usr/GNUstep/Local to suddenly be ~/GNUstep The default location would always be LOCAL. :-) > How would that behavior be defined ... eg how do we specify whether > the SYSTEM domain is /usr rather than /usr/GNUstep/System? > Simply by a configure-time option to gnustep-make to define the > filesystem layout make is to use? We can decide, but I would imagine that when you configure gnustep-make you specify the type of filesystem structure to use ... Presumably you could always manually override on the command-line the installation variables if you know what you're doing. ;-) ... ... But otherwise, gnustep-make will know from how it was configured if that gnustep installation is using a native filesystem (of what type) or a GNUstep filesystem etc. > I'm not sure I understand ... > Your examples are setting the domain from the command line, but I > would have thought that doing it inside the makefile would be common. > > That is to say, most packages would want to be installed in the LOCAL > domain, core packages in the SYSTEM domain, and new code that users > par developing would probably want to be in the USER domain by > default ... but you wouldn't want to have to remember to set a > command-line option to control that every time you typed 'make'. The idea would be that ... 1. stuff that comes pre-installed in your system goes into System 2. stuff that you install yourself goes into Local 3. stuff that you install yourself for yourself only goes into User (keeping in mind that User won't work with Unix-type filesystems) So, the idea is that anything you compile manually goes into Local unless explicitly told otherwise (and consistency is good!). :-) Distributions would of course install the core packages into System ... and could also install a lot of other packages into System! ;-) But if you compile it yourself, by definition it shouldn't go into System. I guess the key concept is that the installation domain is decided by the packager, not by the software author! This is why it shouldn't be set in the GNUmakefile. ;-) In other words ... the difference between System and Local is *not* that "important" packages go in System while "optional" packages go in Local. This attitude just results in all authors forcing their own package [which of course is really important in the author's opinion ;-)] to install into System. ;-) I would go as far as saying that even gnustep-base should have no GNUSTEP_INSTALLATION_DOMAIN set. If I compile all the system manually myself, I wouldn't see anything wrong in having everything end up into Local. Even gnustep-make could go into Local without special losses, so by default it should probably go in there. Suggestions welcome though, if we strictly want gnustep-make and gnustep-base to always be in System, we can easily add GNUSTEP_INSTALLATION_DOMAIN in the GNUmakefile ... setting it on the command-line will always override the value set in the GNUmakefile. So it's not a problem. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
> Would it be an idea to have an option that decides what kind of tree is > going to be used like: > > GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] > We're not far from that ;-) ... that option will be used when configuring gnustep-make. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) > And then GNUSTEP_INSTALLATION_DIR decides where the root is, maybe it > should be called GNUSTEP_FS_ROOT, like in > GNUSTEP_FS_ROOT=[/usr/GNUstep/System|/usr/GNUstep/Local|/usr|/usr/local|/opt] Why not GNUSTEP_INSTALLATION_DOMAIN then, which is an 'abstract' definition of where things should be installed ? gnustep-make would then map it to the local reality. :-) > I understand the use of domains, since it abstracts the filesystem from > the user, but there is no NETWORK equivalent for FHS and WINDOWS, and > some systems like to use /opt, which you rule out. I don't rule anything out ;-) ... you will map your domains to your local filesystem situation in the way you want. You can map something to /opt. You can have Network be the same as Local, or be something different. Those things will be first decided when you configure gnustep-make ... presumably you can also edit the GNUstep.conf file. ;-) > And what does SYSTEM mean on a Unix but non-FHS system, does that mean > /usr or /, or /opt? That will depend on how you configured your gnustep-make. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Nicola Pero schrieb: > I would go as far as saying that even gnustep-base should have no > GNUSTEP_INSTALLATION_DOMAIN set. If I compile all the system manually > myself, I wouldn't see anything wrong in having everything end up > into Local. Even gnustep-make could go into Local without special > losses, so by default it should probably go in there. I agree with the proposal in principle. I was initially worried about /usr/GNUstep/System/Library/Makefiles/GNUstep.(c)sh /usr/GNUstep/System/Library/Makefiles/Additional/ /usr/GNUstep/System/Library/Makefiles/Auxiliary/ But I guess in both cases they "correct" location would be defined by GNUSTEP_MAKEFILES so there might not be an issue here. > Suggestions welcome though, if we strictly want gnustep-make and gnustep-base > to always be in System, we can easily add GNUSTEP_INSTALLATION_DOMAIN in > the GNUmakefile ... setting it on the command-line will always override > the value set in the GNUmakefile. So it's not a problem. ;-) My personal preference is that GNUSTEP_INSTALLATION_DOMAIN should always default to LOCAL. But I don't feel strongly about it. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 9 Oct 2006, at 23:09, Nicola Pero wrote: This option can only be set on the command line, or before including common.make ... but using it in GNUmakefiles should be discouraged as all packages should install by default in the default locations ... except for maybe gnustep-base :-) Thinking about it, I wouldn't want even gnustep-base to set it. If I'm testing the Unix filesystem layout, I wouldn't want gnustep- base to install stuff in /usr ... ;-) It should be installed in /usr/local (or wherever we decide the local stuff goes) unless I explicitly require it to go in /usr. ;-) Comments ? Long established policy is that on a GNUstep system (ie the default situation, where we are not trying to conform to FHS or some other distribution dependent layout), the GNUstep packages (anything part of the GNUstep project) should be installed in the system domain, while contributed packages should be installed in the local domain, and a user's own packages (ie not put in place for everyone by the system administrator) go in the user domain. At the moment this is done automatically for GNUstep packages (such as base, gui, back, gorm) by their setting the installation directory in the makefile. Now, I understand the logic that distributors should determine where the packages they want go ... so certainly there is no debate about the fact that setting GNUSTEP_INSTALLATION_DOMAIN on the command line should override any settiing in the make files. However, I'm not sure that we should be changing the makefiles so that their behavior is no longer to install in their normal locations. I think we have not thought through installation adequately, and I'm very dubious about changing current behavior to something which is not clearly thought through and better than the existing behavior ... change for the sake of change is generally a bad thing. Let's try and decide what would be an improvement over the current behavior. What should 'make install' actually do? 1. A developer working on a new package normally wants it installed where it won't interfere with anyone else ... Clearly installation should be in the User domain. 2. A normal user presumably expects it to change the package to be in a runnable/usable state On GNUstep and MacOS-X systems, this probably means installing into the user domain On non-GNUstep systems, it's far less clear ... there is no standard location where user specific binaries may be found, and usual behavior is to install into the Local domain, but that generally requires root privilege or something similar. 3. A system administrator wants it to be installed for all users ... This means installation in the Local domain, unless they are upgrading part of a distribution where GNUstep is 'native', in which case they want GNustep packages in the System domain 4. I think standard expectation is that 'make install' installs the package wherever it was configured to go ... ie the decision about where to install was taken at 'configure' time using something like -- prefix= and if this is not specified then the installation location is decided by the package itsself (normally the 'local' domain). So, how about this for an idea ... The make scripts are made more intelligent and capable of asking the user what to do if they try to install in a domain they don't have access to (maybe using su to complete the installation if given the correct password). This is important for unprivileged users trying to install packages where the installation location is the system or local domain. The make scripts also interpret the installation domain according to the filesystem layout ... so if a package wants to be installed in the system domain on a system where non-native stuff has to go in / opt, (ie the local domain) then the filesystem layout configured into gnustep-make should override the domain specified (ie on such systems the system domain is the same as the local domain for purposes of installing software). a. the default installation location is the local domain b. a makefile may override that to supply a package specific default c. the command line overrides that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
> a. the default installation location is the local domain > b. a makefile may override that to supply a package specific default > c. the command line overrides that. That's exactly my proposal. :-) Except that, of course, I'd like to discourage b. as a practice. ;-) The main reason being that all software should install consistently in the same way. If every software author chooses a different default domain, there is no consistency. :-/ Also it would be pretty bad to have software install by default in /usr on a Unix type filesystem ... I would want the stuff to install following default conventions like any other Unix system (ie, stuff by default installs into /usr/local or /opt or whatever). Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to install them into System instead when they package though). Makes sense ? Thanks PS: would gnustep-base work if you install it in Local ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
> 1. A developer working on a new package normally wants it installed > where it won't interfere with anyone else ... > Clearly installation should be in the User domain. PS: Keep in mind that the User domain won't work if you don't source GNUstep.sh (and the option of not sourcing GNUstep.sh is now available). I like the User domain and would personally source GNUstep.sh just to be able to use it :-) But some people might not want to do it, especially with the Unix FHS. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: GNUSTEP_INSTALLATION_DOMAIN
> -Original Message- > From: Nicola Pero > > Also it would be pretty bad to have software install by > default in /usr on > a Unix type > filesystem ... I would want the stuff to install following default > conventions like > any other Unix system (ie, stuff by default installs into > /usr/local or > /opt or whatever). > > Anyway I suggest as a reasonable agreement, we'll use b. to set the > installation domain > as System for the 4 core packages (make, base, gui, back). All other > packages should have > no default set and so install by default in Local (packagers are > encouraged to install them > into System instead when they package though). Makes sense ? > Sounds good. I guess, like Richard, I'm conflicted. I know that every source code package I download is installed in /usr/local. But GNUstep has used the /usr[/GNUstep] convention for so long it might be confusing to change that. And any distribution is going to set their own location anyway. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 11 Oct 2006, at 10:18, Nicola Pero wrote: a. the default installation location is the local domain b. a makefile may override that to supply a package specific default c. the command line overrides that. That's exactly my proposal. :-) Except that, of course, I'd like to discourage b. as a practice. ;-) The main reason being that all software should install consistently in the same way. If every software author chooses a different default domain, there is no consistency. :-/ On consideration, I think we should stick to current conventions ... GNUstep packages go in the System domain and on GNUstep (ie third party contributed) packages go in the Local domain. I don't think we've ever suggested that every author should choose a different domain. Also it would be pretty bad to have software install by default in / usr on a Unix type filesystem ... I would want the stuff to install following default conventions like any other Unix system (ie, stuff by default installs into /usr/ local or /opt or whatever). Sure ... On a system where the traditional GNUstep filesystem layout is not used, the System domain should be /usr/local or /opt or whatever, unless the people managing a distribution want it to be /usr on that distribution of course. I imagine that on such systems the System and Local domains might be the same place. Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to install them into System instead when they package though). Makes sense ? No ... not really. The System domain is for all system packages, not just a few core libraries. That means by default, all packages which are part of the GNUstep project ... though people putting together distributions or adding GNUstep stuff to other systems would of course have their own policy (overriding the defaults) about what packages go where. I would like to see *more* packages brought into GNUstep and the System domain rather than having things excluded from it, as I feel that it would be good to have a complete environment. For instance, it would be nice if GNUMail was part of GNUstep. PS: would gnustep-base work if you install it in Local ? Yes, afaik. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
> On consideration, I think we should stick to current conventions ... Ok ... but then you seem to have a weird perception of the current conventions ... ;-) The GNUstep filesystem document (which took ages of mailing list flamewars to write) explicitly says that -- "Every software (except for gnustep-make, gnustep-base, gnustep-gui and gnustep-back which by default install into the System domain) should install by default into the Local domain, so that if you download a source tarball of the software and you install it, it installs by default in the right place for this operation (the Local domain). Distributions should override this default manually when they package the software they want to distribute as part of their distribution, so that in that case the software is installed in the System domain." It has been saying that for the past few years, so I guess that's what the current convention is. ;-) > On a system where the traditional GNUstep filesystem layout is not > used, the System domain should be /usr/local or /opt or whatever, > unless the people managing a distribution want it to be /usr on that > distribution of course. I imagine that on such systems the System > and Local domains might be the same place. I don't agree at all ... the System domain will of course be /usr, and the Local domain will be /usr/local. Otherwise, why do we have domains at all ? :-) Presumably FHS compliance will also require that ... stuff coming with the distribution goes into System (/usr), stuff you manually install yourself from sources goes into Local (/usr/local) ... feels obvious. Let's make an example. Let's say I take gnustep-make and gnustep-base from Debian packages. They use Debian FHS policy, so no doubt System will be /usr and Local will be /usr/local (or /opt, whatever). They will then be installed in /usr. Which is great, as I know /usr is stuff managed by Debian. Then, I download sqlclient and compile it manually. Should it go in /usr or in /usr/local ? Obviously in /usr/local. Which is great, as I know that /usr/local is stuff I installed myself. sqlclient is still part of GNUstep, but by default if I download a package, it goes into /usr/local. That would work exactly like any other GNU/Unix/Debian package. Which is the whole reason we're working for FHS integration etc. etc. People want to be able to use GNUstep like they use any other package, without special setups / conventions / etc. >> Anyway I suggest as a reasonable agreement, we'll use b. to set the >> installation domain >> as System for the 4 core packages (make, base, gui, back). All other >> packages should have >> no default set and so install by default in Local (packagers are >> encouraged to install them >> into System instead when they package though). Makes sense ? > > No ... not really. The System domain is for all system packages, not > just a few core libraries. > I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) The reason to have separate System and Local domains is not to have "first class" packages in System and "second class" packages in Local. The reason is that when you look at your hard disk, you know what is managed by your distribution and you shouldn't touch, and what you are managing yourself and can mess up as you wish. The fact that a package belongs to GNUstep or not doesn't tell me anything about whether my distribution/packaging system is managing it or whether I installed it from scratch. They are separate issues. ;-) > I would like to see *more* packages brought into GNUstep and the > System domain rather than having things excluded from it, as I feel > that it would be good to have a complete environment. For instance, > it would be nice if GNUMail was part of GNUstep. The fact that something is installed by the packager into the System domain or not has nothing to do with being part of the GNUstep project. It would be the same as saying that things installed in /usr are part of the GNU project, while things installed in /usr/local are not. But these are totally unrelated issues. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On Thu, 12 Oct 2006 22:00:18 +0200 (CEST), "Nicola Pero" <[EMAIL PROTECTED]> said: [...] >> On a system where the traditional GNUstep filesystem layout is not >> used, the System domain should be /usr/local or /opt or whatever, >> unless the people managing a distribution want it to be /usr on that >> distribution of course. I imagine that on such systems the System >> and Local domains might be the same place. > I don't agree at all ... the System domain will of course be /usr, and > the Local domain will be /usr/local. Otherwise, why do we have > domains at all ? :-) Well, according to the FHS, if you download GNUstep and compile it on your own (not obtaining it from your distribution), then it should go under /usr/local, or /opt. In which case, Local and System are probably equivalent, since GNUstep itself is a "local" package, and there is no distribution involved. But if you obtain GNUstep from your distribution, then it should definitely go under /usr. So IMHO by default, the System and Local domains should be /usr/local, but the distributions will of course override that for their own packages. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 12 Oct 2006, at 21:43, David Ayers wrote: Nicola Pero schrieb: Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to install them into System instead when they package though). Makes sense ? No ... not really. The System domain is for all system packages, not just a few core libraries. I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) Indeed, and I believe this is the core argument. The way I see it is, installing a self compiled -make and -base into the Local domain (potentially hiding the packager installation in the System domain) is analogous to installing a self compiled gcc into /usr/local hiding the system gcc (and related libraries like libobjc). Yes ... it's why I think there should be a distinction made between building/installing a package as the maintainter of a distribution and building/installing as a normal user. In both cases the package should automatically be installed in the correct place. The normal case should be that you do *not* have to specify where it should go. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Richard Frith-Macdonald schrieb: > > On 12 Oct 2006, at 21:43, David Ayers wrote: > >> Nicola Pero schrieb: >> >>>>> Anyway I suggest as a reasonable agreement, we'll use b. to set >>>>> the installation domain as System for the 4 core packages (make, >>>>> base, gui, back). All other packages should have no default set >>>>> and so install by default in Local (packagers are encouraged to >>>>> install them into System instead when they package though). Makes >>>>> sense ? >>>> >>>> >>>> No ... not really. The System domain is for all system packages, not >>>> just a few core libraries. >>>> >>> >>> I agree ... but who decides what are the system packages ? Not us. :-) >>> >>> It's decided by the packagers. ;-) >>> >> >> Indeed, and I believe this is the core argument. >> >> The way I see it is, installing a self compiled -make and -base into the >> Local domain (potentially hiding the packager installation in the System >> domain) is analogous to installing a self compiled gcc into /usr/local >> hiding the system gcc (and related libraries like libobjc). > > > Yes ... it's why I think there should be a distinction made between > building/installing a package as the maintainter of a distribution and > building/installing as a normal user. In both cases the package should > automatically be installed in the correct place. The normal case > should be that you do *not* have to specify where it should go. > Well I think the dispute is based on the perception of the role of the GNUstep project. Just like source distributed by the gcc project doesn't install into /usr but into /usr/local, I don't think it is the GNUstep's -make/-base/-gui/-back packages prerogative to install into 'System'. Just like Debian and other OS distributions have their builds setup to install gcc into /usr, I think it would be a GNUstep distributions prerogative to install -make/-base/-gui/-back into System. I.e. if we hosted a distribution like SimplyGNUstep which provided the build scripts to build a GNUstep System, then I think it would be that projects prerogative to set the GNUSTEP_INSTALLATION_DOMAIN in it's build scripts. I'm only trying to make myself clear and I'm not on a mission to convince anyone here who simply has a different view. So I'll gladly clarify any misunderstandings but will refrain from further lobbying. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 12 Oct 2006, at 21:00, Nicola Pero wrote: On consideration, I think we should stick to current conventions ... Ok ... but then you seem to have a weird perception of the current conventions ... ;-) The GNUstep filesystem document (which took ages of mailing list flamewars to write) explicitly says that -- "Every software (except for gnustep-make, gnustep-base, gnustep-gui and gnustep-back which by default install into the System domain) should install by default into the Local domain, so that if you download a source tarball of the software and you install it, it installs by default in the right place for this operation (the Local domain). Distributions should override this default manually when they package the software they want to distribute as part of their distribution, so that in that case the software is installed in the System domain." It has been saying that for the past few years, so I guess that's what the current convention is. ;-) No ... I guess it's just what the filesystem document says ... not what's actually done. AFAIK nothing has been changed to do what that says, perhaps because people didn't notice the change, or perhaps because it didn't make sense to them? On a system where the traditional GNUstep filesystem layout is not used, the System domain should be /usr/local or /opt or whatever, unless the people managing a distribution want it to be /usr on that distribution of course. I imagine that on such systems the System and Local domains might be the same place. I don't agree at all ... the System domain will of course be /usr, and the Local domain will be /usr/local. Otherwise, why do we have domains at all ? :-) I think you completely miss the point ... being that the managers of a distribution decide where they want things to install on their distribution. There is a BIG distinction between distribution managers installing packages as part of a distribution and normal users installing additional packages. Presumably FHS compliance will also require that ... stuff coming with the distribution goes into System (/usr), stuff you manually install yourself from sources goes into Local (/usr/local) ... feels obvious. Sure ... exactly what I said. The location of stuff coming with the distribution is handled by the managers of the distribution. Let's make an example. Let's say I take gnustep-make and gnustep-base from Debian packages. They use Debian FHS policy, so no doubt System will be /usr and Local will be /usr/local (or /opt, whatever). They will then be installed in /usr. Which is great, as I know /usr is stuff managed by Debian. Only if they are part of the debian distribution ... ie the managers of the distribution want to put them there. If they are *not* part of the distribution, I think it's debian policy to put them in /usr/local. Then, I download sqlclient and compile it manually. Should it go in /usr or in /usr/local ? Obviously in /usr/local. Which is great, as I know that /usr/local is stuff I installed myself. sqlclient is still part of GNUstep, but by default if I download a package, it goes into /usr/local. Sure ... you are not the manager of the distribution, but the distribution supplied GNUstep stuff, so for you to conform to distribution conventions, the system domain for installation should be set to /usr/local on that system. NB. the system domain for installation purposes would not be the same as the system domain for all other purposes in this case. It depends how you want to look at it, but the point is that the installation process should not treat installation by a normal user the same as installation by the package distributor ... a normal user should not be overwriting packages provided by the system. Take the base library for instance ... it's default location is the system domain. When a distribution maintainer installs it they may want the system domain to be /usr so it goes in /usr. However, when a normal user downloads and installs a version it should get installed in /usr/local because normal users should not be installing into /usr. The easy way to do this is for the maintainer to build/install using a copy of the make system where the system domain is set to /usr, but to send out the distribution with a copy of the make system set to install system domain packages into /usr/local That would work exactly like any other GNU/Unix/Debian package. Which is the whole reason we're working for FHS integration etc. etc. People want to be able to use GNUstep like they use any other package, without special setups / conventions / etc. Exactly what I'm proposing. Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to i
Re: GNUSTEP_INSTALLATION_DOMAIN
Nicola Pero wrote: Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] We're not far from that ;-) ... that option will be used when configuring gnustep-make. It is -base which decides what goes where so we shouldn't we really be configuring base, not -make? Decoupling the dependencies is a good thing, IMHO. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) Then every application, at launch time, must set up the whole fs structure? >> And then GNUSTEP_INSTALLATION_DIR decides where the root is, maybe it should be called GNUSTEP_FS_ROOT, like in GNUSTEP_FS_ROOT=[/usr/GNUstep/System|/usr/GNUstep/Local|/usr|/usr/local|/opt] Why not GNUSTEP_INSTALLATION_DOMAIN then, which is an 'abstract' definition of where things should be installed ? gnustep-make would then map it to the local reality. :-) For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? I'd prefer something a little more like: GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) GNUSTEP_INSTALL_INTO GNUSTEP_INSTALL_DESTINATION or perhaps we should be thinking more along packaging lines... GNUSTEP_PACKAGE_LOCATION Packagers can easily add a line to their makefile or preamble this way... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
> NB. the system domain for installation purposes would not be the same > as the system domain for all other purposes in this case. This is a new, confusing distinction that you are introducing and that would make everything lot more complicated. ;-) You're proposing to introduce 'installation domains' as separated from 'runtime domains', ie, you could have /usr/lib as the runtime System/Libraries dir, while /usr/local/lib is the installation System/Libraries dir. That would be a hell lot of a complication (and there is more complexity for packagers). ;-) Hopefully we can negotiate some other solution, as I don't want to add such complexity. :-/ I had written more on this, but I don't want to discuss it. Too complex. ;-) >> I agree ... but who decides what are the system packages ? Not >> us. :-) >> >> It's decided by the packagers. ;-) > > But we *are* the packagers for the *default* system ... the GNUstep > system. > We only distribute the source code, not binaries. If we distribute binaries, then yes, we should install the GNUstep ones into System. When we distribute source code, it should install by default into Local. I agree we should have binaries distributions of the "default" system, and those should install all GNUstep packages into System. In fact, anything that they package should be put into System. That would be great. :-) > Only where you are using a system with GNUstep stuff pre-installed. > Many (most?) people are not using such a system ... they have > installed the 'GNUstep system' on their machine. > It's located in /usr/GNUstep. > The standard packages are in /usr/GNUstep/System > Other stuff is in /usr/GNUstep/Local Core developers (/most people at the moment) that compile and install from scratch are not using a distribution. ;-) (guess I need to clarify that by 'distribution' I mean 'binary distribution'). When you're not using a distribution, the difference between System and Local is irrelevant. They could well be the same ... you're installing everything from scratch anyway. :-) In fact, why would you care where things go at all ? It could well all go into Local and you wouldn't notice. At the moment, software installs randomly into System or Local. Nobody cares because nobody is using a distribution. When occasionally they look at the directories they might like seeing 'core' stuff in System and other stuff in Local, but it's only aesthetical. If we had distributions (and we hope to get more of that as a result of the massive simplification and "Unix nativization"), then people would start to get some packages from the distribution, and to compile some of them manually. Then the difference starts to be important. If you're getting -make and -base from the binary distribution, but you're installing -gui from sources, you would want -make and -base into /usr/GNUstep/System, and -gui into /usr/GNUstep/Local ... and you start to care about the difference, because stuff in /usr/GNUstep/System is package-managed, while stuff in /usr/GNUstep/Local is not. The standard GNU solution that everyone is using is that source code by default installs into Local unless you specify differently. Users do nothing and it all works; packagers simply specify differently, which is a single install flag, and it all works. We should do the same IMO. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
>>> Would it be an idea to have an option that decides what kind of tree is >>> going to be used like: >>> >>> GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] >>> >> >> We're not far from that ;-) ... that option will be used when configuring >> gnustep-make. > > It is -base which decides what goes where so we shouldn't we really be > configuring base, not -make? > > Decoupling the dependencies is a good thing, IMHO. You would be able to change your filesystem structure at any time by editing your GNUstep.conf. GNUstep.conf is initially created by gnustep-make, so it makes sense to have the option there. Things should be decoupled ... -make and -base don't really talk or depend on each other. Everything is driven by GNUstep.conf. You'll be able to use -base (/any other GNUstep software) without -make if you want, if you set manually everything in GNUstep.conf. >> We just need to save the configured filesystem structure in GNUstep.conf, >> and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done >> (except >> that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that >> context). ;-) >> > Then every application, at launch time, must set up the whole fs structure? > Yes ... we're not really "almost done". :-( ... we also need to have gnustep-base load the directory structure from GNUstep.conf and use it when searching for stuff at runtime :-/ > For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? > > I'd prefer something a little more like: > > GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) The problem with this is that it would break backwards compatibility ;-) There are makefiles out there that might be using it in the old meaning. We can't break those, at least not when they are used in the old context. ;-) > GNUSTEP_INSTALL_INTO > GNUSTEP_INSTALL_DESTINATION > > or perhaps we should be thinking more along packaging lines... > > GNUSTEP_PACKAGE_LOCATION > > Packagers can easily add a line to their makefile or preamble this way... I don't really have an opinion, I like GNUSTEP_INSTALLATION_DOMAIN but we can change the option name, it's not a problem. :-) Comments/suggestions on the name are welcome. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
>> I don't agree at all ... the System domain will of course be /usr, and >> the Local domain will be /usr/local. Otherwise, why do we have >> domains at all ? :-) > > Well, according to the FHS, if you download GNUstep and compile it on > your own (not obtaining it from your distribution), then it should go > under /usr/local, or /opt. In which case, Local and System are probably > equivalent, since GNUstep itself is a "local" package, and there is no > distribution involved. > > But if you obtain GNUstep from your distribution, then it should > definitely go under /usr. Yes :-) > So IMHO by default, the System and Local domains should be /usr/local, > but the distributions will of course override that for their own > packages. I would rather say that, by default, System is /usr and Local is /usr/local, and source packages install by default into Local. Distributions will override that for their own packages. If System/Local domains are the same (/usr/local), then we would ignore /usr, so resources from system packages in /usr would not be found. Really, if System packages are in /usr, the System domain should be available as /usr. This means resources/frameworks/bundles/etc. in System (/usr) would be available/visibile to -make, -base and to any other gnustep stuff (such as openapp or whatever). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Nicola Pero wrote: Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] We're not far from that ;-) ... that option will be used when configuring gnustep-make. It is -base which decides what goes where so we shouldn't we really be configuring base, not -make? Decoupling the dependencies is a good thing, IMHO. You would be able to change your filesystem structure at any time by editing your GNUstep.conf. GNUstep.conf is initially created by gnustep-make, so it makes sense to have the option there. Yes, but it doesn't need to be. It's a development tool. Things should be decoupled ... -make and -base don't really talk or depend on each other. Not entirely true. Currently -base depends on -make for configuration. Everything is driven by GNUstep.conf. You'll be able to use -base (/any other GNUstep software) without -make if you want, if you set manually everything in GNUstep.conf. That's right. Yet if -base generated GNUstep.conf then you wouldn't need to do that. You could replace -make with any other tool that could translate from the GNUmakefiles. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) Then every application, at launch time, must set up the whole fs structure? Yes ... we're not really "almost done". :-( ... we also need to have gnustep-base load the directory structure from GNUstep.conf and use it when searching for stuff at runtime :-/ For long lived processes this might be fine but for short lived tools you're imposing a considerable startup delay. I added PLATFORM_SUPPORT as a step in avoiding that. If you said something like: GNUSTEP_INSTALLATION_DOMAIN=PLATFORM_LIBS you'd get your library installing into /usr/lib and so forth. So any GNUSTEP_* spec uses OpenStep domain layout. Any PLATFORM_* spec uses the local platform specifics. For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? I'd prefer something a little more like: GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) The problem with this is that it would break backwards compatibility ;-) > There are makefiles out there that might be using it in the old meaning. We can't break those, at least not when they are used in the old context. ;-) Well, yes. Making it *ION_DIRECTORY would solve that while keeping the semantic idea. GNUSTEP_INSTALL_INTO GNUSTEP_INSTALL_DESTINATION or perhaps we should be thinking more along packaging lines... GNUSTEP_PACKAGE_LOCATION Packagers can easily add a line to their makefile or preamble this way... I don't really have an opinion, I like GNUSTEP_INSTALLATION_DOMAIN but we can change the option name, it's not a problem. :-) Comments/suggestions on the name are welcome. :-) Cool. Others? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
>> Things should be decoupled ... -make and -base don't really talk or depend >> on each other. > > Not entirely true. Currently -base depends on -make for configuration. > Thanks, I see your point ... which is a very good one :-) You're suggesting that, for example, in a binary distribution (say, Debian) you could install gnustep-base without installing gnustep-make. Then you can also install any other GNUstep software that is binary packaged by the distribution. You don't need gnustep-make, because everything is in the FHS locations and you're not building anything, you're just installing binary packages. I agree it would be a nice thing :-) In that case, yes, you would need GNUstep.conf, yet you have no gnustep-make installed. I suppose the right way of addressing the issue is to create a 'gnustep-common' package, that only installs GNUstep.conf. Then, on top of that, you can install gnustep-make and/or gnustep-base; you only install gnustep-make if you want to build. We could make all this explicit by extracting the creation of GNUstep.conf into a separate software ... to be installed before gnustep-make. It sounds very clumsy though ;-) At the moment, I'd leave everything as it is (a packager could still install GNUstep.conf in a separate package to get the effect above). Moving the creation of GNUstep.conf into gnustep-base doesn't make much sense, because gnustep-make can't work without it. You may want to use gnustep-make without gnustep-base (eg, for building documentation or resources or java stuff, or for building using non-gnustep-base foundation libraries, eg on apple-apple-apple or gnu-fd-nil), and at the moment you can't build gnustep-base without gnustep-make anyway ;-) Anyway, good idea to keep it in mind, I mean, yes, conceptually, the step of creating GNUstep.conf is separate from gnustep-make and gnustep-base. It's a "preliminary" step if you want. ;-) >> Yes ... we're not really "almost done". :-( ... we also need to have >> gnustep-base load >> the directory structure from GNUstep.conf and use it when searching for stuff >> at runtime :-/ > > For long lived processes this might be fine but for short lived tools you're > imposing a considerable startup delay. There is already such a delay, since we are already reading GNUstep.conf. I doubt adding ten more lines or so to read would make any difference in speed. If we could avoid reading the file altogether, that would be faster. ;-) I imagine the 20 lines GNUstep.conf file will always be in the kernel cache so it will all be extremely fast. Maybe we could benchmark it, but even for a Unix command-line utility that has to be as fast as 'grep' or 'sed' or those thingies, I'm not sure it would make a measurable difference. If it makes a considerable difference, presumably you'd disable GNUstep.conf and just run from hardcoded values. That would work and be as fast as you can get :-) > I added PLATFORM_SUPPORT as a step in avoiding that. > > If you said something like: > > GNUSTEP_INSTALLATION_DOMAIN=PLATFORM_LIBS > > you'd get your library installing into /usr/lib and so forth. > > So any GNUSTEP_* spec uses OpenStep domain layout. > Any PLATFORM_* spec uses the local platform specifics. Oh ... I see. I looked at that ... but the current idea/trend is rather that, when you use the Unix FHS (for example), the GNUstep dirs are mapped onto local Unix FHS dirs. All access to the dirs goes through the API anyway. So, GNUSTEP_SYSTEM_ROOT/Tools ends up mapped into /usr/bin. GNUSTEP_LOCAL_ROOT/Library/Libraries is mapped to /usr/local/lib, etc. Of course the libs have to do the mapping from the GNUstep API to the native filesystem. This mapping comes from GNUstep.conf (or is hardcoded in the lib). So, rather than have both the GNUstep filesystem and the native filesystem in the same installation, you'd have either the GNUstep one or the native one. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 13 Oct 2006, at 02:33, Nicola Pero wrote: NB. the system domain for installation purposes would not be the same as the system domain for all other purposes in this case. This is a new, confusing distinction that you are introducing and that would make everything lot more complicated. ;-) You're proposing to introduce 'installation domains' as separated from 'runtime domains', ie, you could have /usr/lib as the runtime System/Libraries dir, while /usr/local/lib is the installation System/Libraries dir. That would be a hell lot of a complication (and there is more complexity for packagers). ;-) When writing the last email I started writing about how the term domain might be confusing ... but then gave up and deleted that paragraph. I'm really don't want complexity. What I want is to make things simple to use, so people don't need to add extra arguments to their make command to say where things should go. Hopefully we can negotiate some other solution, as I don't want to add such complexity. :-/ I agree. I had written more on this, but I don't want to discuss it. Too complex. ;-) I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) But we *are* the packagers for the *default* system ... the GNUstep system. We only distribute the source code, not binaries. If we distribute binaries, then yes, we should install the GNUstep ones into System. When we distribute source code, it should install by default into Local. I agree we should have binaries distributions of the "default" system, and those should install all GNUstep packages into System. In fact, anything that they package should be put into System. That would be great. :-) Only where you are using a system with GNUstep stuff pre-installed. Many (most?) people are not using such a system ... they have installed the 'GNUstep system' on their machine. It's located in /usr/GNUstep. The standard packages are in /usr/GNUstep/System Other stuff is in /usr/GNUstep/Local Core developers (/most people at the moment) that compile and install from scratch are not using a distribution. ;-) (guess I need to clarify that by 'distribution' I mean 'binary distribution'). OK .. I don't hugely object to the principle of installing in Local ... but I mostly haven't seen it clearly argued for/justified. The argument based on installing like general unix packages, in /usr/ local, donesn't make sense to me since /usr/local is not necessarily the same thing as Local. We can easily install in the same place as standard unix packages without installing in Local. The subtly different argument that anything not built as part of a distribution should install in the Local domain rather than the system domain (because only the distributor should touch the System domain) makes much more sense, but is complicated by other factors ... 1. the definition of a distribution ... since the GNUstep project is, in a sense, a distribution 2. inconsistency, since existing practice is to install the core libraries and some other tools in System, and in the file layout document you pointed out that 'official' policy is to store the core libraries in System. 3. historical. we are talking about changing behavior and where things go by default Now, I think we can ignore 1 (now we are clear about it) since that's really just semantics, the only practical reason for considering the GNUstep project like a binary distribution is because some people (well, me at least) happen to have thought of it that way and because it largely fits in with (3) the historical practice of where things are installed. I find 2 a real annoyance ... the idea of putting GNUstep stuff in system was consistent with my understanding of 1, but this (currently documented) notion of putting the core libraries in System and everything else in Local makes no sense. Surely it should be one or the other? I'm happy to put everything in Local (if we define that the GNUstep project is not a distribution) or everything in System (if we define a distribution as a binary distribution), but I very much dislike a mixture. 3. We can probably live with a change i behavior. However ... here we come to a point where maybe I would quite like to see the installation code made more complex. The make package has just been cleaned up a lot to avoid confusion and conflicts between normal,debug, and profile libraries, but now we are likely to get multiple copies of packages installed in different domains. This should not cause horrible crashes and failures to run, but is still likely to cause confusion. How hard would it be for gnustep-make to spot that we are installing a duplicate, tell us which domain the existing version is in, and ask us about it? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http:
Re: GNUSTEP_INSTALLATION_DOMAIN
On 13 Oct 2006, at 04:58, Nicola Pero wrote: Things should be decoupled ... -make and -base don't really talk or depend on each other. Not entirely true. Currently -base depends on -make for configuration. Thanks, I see your point ... which is a very good one :-) You're suggesting that, for example, in a binary distribution (say, Debian) you could install gnustep-base without installing gnustep-make. Then you can also install any other GNUstep software that is binary packaged by the distribution. You don't need gnustep-make, because everything is in the FHS locations and you're not building anything, you're just installing binary packages. I agree it would be a nice thing :-) In that case, yes, you would need GNUstep.conf, yet you have no gnustep-make installed. I suppose the right way of addressing the issue is to create a 'gnustep-common' package, that only installs GNUstep.conf. Then, on top of that, you can install gnustep-make and/or gnustep- base; you only install gnustep-make if you want to build. We could make all this explicit by extracting the creation of GNUstep.conf into a separate software ... to be installed before gnustep-make. It sounds very clumsy though ;-) At the moment, I'd leave everything as it is (a packager could still install GNUstep.conf in a separate package to get the effect above). This all sounds complex ... and seems to be based on accepting both that gnustep-base depends on gnustep-make for configuration and the assumption that this is a problem. The flaw in that is that base does not depend on make for config information (unless it's been broken recently), it merely uses it at configure/build time if it is present and not overridden. Even if base did depend on make for config information, I don't see it as much of a problem, since if we ever had another package capable of building the base library I'm sure it could be made able to provide any necessary config information for it too. Moving the creation of GNUstep.conf into gnustep-base doesn't make much sense, because gnustep-make can't work without it. You may want to use gnustep-make without gnustep-base (eg, for building documentation or resources or java stuff, or for building using non-gnustep-base foundation libraries, eg on apple-apple-apple or gnu-fd-nil), and at the moment you can't build gnustep-base without gnustep-make anyway ;-) Yes, gnustep-make required GNUstep.conf, but gnustep-base does not. But even if it was required by base, we could deal with the problem when we produced another package capable of building base. Anyway, good idea to keep it in mind, I mean, yes, conceptually, the step of creating GNUstep.conf is separate from gnustep-make and gnustep-base. It's a "preliminary" step if you want. ;-) Yes, analagous to running a configure script ... it's where you set up various options. Yes ... we're not really "almost done". :-( ... we also need to have gnustep-base load the directory structure from GNUstep.conf and use it when searching for stuff at runtime :-/ For long lived processes this might be fine but for short lived tools you're imposing a considerable startup delay. There is already such a delay, since we are already reading GNUstep.conf. I doubt adding ten more lines or so to read would make any difference in speed. If we could avoid reading the file altogether, that would be faster. ;-) Yes, but not much faster ... on my system it takes half a millisecond to do the whole process of reading and parsing configuration info ... that includes loading both the system GNUstep.conf and my user specific one overriding some values in the system-wide one. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On Fri, 13 Oct 2006 05:58:20 +0200 (CEST), "Nicola Pero" <[EMAIL PROTECTED]> said: >>> Things should be decoupled ... -make and -base don't really talk or >>> depend on each other. >> >> Not entirely true. Currently -base depends on -make for >> configuration. >> > Thanks, I see your point ... which is a very good one :-) > You're suggesting that, for example, in a binary distribution (say, > Debian) you could install gnustep-base without installing > gnustep-make. Well, since you mention Debian... ;) Debian currently splits off parts of gnustep-make into a package named gnustep-common. gnustep-common includes GNUstep.conf, openapp, GNUstep.sh, etc... all the stuff that a regular user might want for running GNUstep programs, without all the Makefiles. (It's nice to be on a mailing list where, when someone wants to use a binary distribution in an example, it's usually Debian. ;) ) [...] > I suppose the right way of addressing the issue is to create a > 'gnustep-common' package, that only installs GNUstep.conf. > Then, on top of that, you can install gnustep-make and/or > gnustep-base; you only install gnustep-make if you want to build. > We could make all this explicit by extracting the creation of > GNUstep.conf into a separate software ... to be installed before > gnustep-make. It sounds very clumsy though ;-) > At the moment, I'd leave everything as it is (a packager could still > install GNUstep.conf in a separate package to get the effect above). I agree. My personal recommendation would be that, in terms of source tarballs, you should keep GNUstep.conf inside gnustep-make. If someone downloads the sources, well, they'll need gnustep-make anyways. Then you can let the binary distributors do what they want, and split off a gnustep-common package if they want to. Of course, I'm biased, because that's how we're doing things in Debian. ;) -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Another thought about GNUSTEP_INSTALLATION_DOMAIN
It occurs to me that NSSearchPathForDirectoriesInDomains() has a mask of domains as the second argument. That means that code looking for resources is expected to know which domain it should be finding them in ... rather than just looking in all domains. So there is an inbuilt assumption supported by the API that certain packages are installed in certain domains. We could go through all code and make sure that whenever NSSearchPathForDirectoriesInDomains() is used, its second argument is the mask of all domains ... so that it should work wherever packages are installed. The downsides of that are ... 1. we don't control all the code using that function 2. it may not be a good idea to load some resources from some domains (eg security) However, we could just say 1. it's the programmers fault if they depend on a resource in a particular location, and well written code should cope 2. security issues should be addressed independently anyway But if we do that I think we need to document it very clearly. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Another thought about GNUSTEP_INSTALLATION_DOMAIN
On 13 Oct 2006, at 09:32, Richard Frith-Macdonald wrote: It occurs to me that NSSearchPathForDirectoriesInDomains() has a mask of domains as the second argument. That means that code looking for resources is expected to know which domain it should be finding them in ... rather than just looking in all domains. So there is an inbuilt assumption supported by the API that certain packages are installed in certain domains. We could go through all code and make sure that whenever NSSearchPathForDirectoriesInDomains() is used, its second argument is the mask of all domains ... so that it should work wherever packages are installed. The downsides of that are ... 1. we don't control all the code using that function 2. it may not be a good idea to load some resources from some domains (eg security) However, we could just say 1. it's the programmers fault if they depend on a resource in a particular location, and well written code should cope 2. security issues should be addressed independently anyway But if we do that I think we need to document it very clearly. Searching through the base library I see that it currently expects to find the SSL bundle, the gdomap nameserver executable, the gdnc notifcation server executable and system documentation projects in the System domain. So, as it currently stands, gnustep-base would *mostly* work if installed in a non-System domain, but not entirely. I guess there are other similar dependencies and cases of reduced functionality in many other bits of software. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Another thought about GNUSTEP_INSTALLATION_DOMAIN
On Oct 13, 2006, at 5:09 AM, Richard Frith-Macdonald wrote: On 13 Oct 2006, at 09:32, Richard Frith-Macdonald wrote: It occurs to me that NSSearchPathForDirectoriesInDomains() has a mask of domains as the second argument. That means that code looking for resources is expected to know which domain it should be finding them in ... rather than just looking in all domains. So there is an inbuilt assumption supported by the API that certain packages are installed in certain domains. We could go through all code and make sure that whenever NSSearchPathForDirectoriesInDomains() is used, its second argument is the mask of all domains ... so that it should work wherever packages are installed. The downsides of that are ... 1. we don't control all the code using that function 2. it may not be a good idea to load some resources from some domains (eg security) However, we could just say 1. it's the programmers fault if they depend on a resource in a particular location, and well written code should cope 2. security issues should be addressed independently anyway But if we do that I think we need to document it very clearly. Searching through the base library I see that it currently expects to find the SSL bundle, the gdomap nameserver executable, the gdnc notifcation server executable and system documentation projects in the System domain. So, as it currently stands, gnustep-base would *mostly* work if installed in a non-System domain, but not entirely. I'm getting a bit confused trying to follow this thread. I thought the original desire was simply to allow GNUstep libs in locations like /usr/lib and resources in /usr/share, etc.. The use of the term "GNUSTEP_INSTALLATION_DOMAIN" confused the issue by being unclear about whether GNUstep's internal map (System, Local, User domains) or the external situation on Unix installations (/usr, /opt, etc.) was referred to. So please pardon me if the next paragraph is off (hopefully not). IMHO GNUstep is already beyond the point where changes that significantly affect what is seen internally by GNUstep programs should be considered. Base is post-1.0, and there are a lot of applications out there. If you want to tweak where GNUstep resources are installed on the host filesystem, that is one thing. Making internal changes that enhance code compatibility with OS X is worth consideration as well, but suddenly requiring programs to search everywhere for what were formerly system resources, simply to make installation cleaner on one type of deployment platform (that not everyone thinks is the most important in the long run for GNUstep) is a bad thing. It was difficult enough adapting to the round of changes when GNUstep.conf was introduced, and I daresay there is still confusion amongst app developers as to the respective roles of GNUstep.conf and GNUstep.[c]sh. While the benefits of FHS installation are nonzero, the amount of initial disruption and any possible divergence in OS X compatibility should be carefully considered. Also, I suggest that an explicit policy for what goes in System domain for GNUstep be developed, following as closely as possible what OS X does. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Another thought about GNUSTEP_INSTALLATION_DOMAIN
> I'm getting a bit confused trying to follow this thread. [...] Yes, the thread might be confusing. Here is a summary of the changes that we are discussing in the thread -- * Using GNUSTEP_INSTALLATION_DOMAIN instead of GNUSTEP_INSTALLATION_DIR. You can keep using GNUSTEP_INSTALLATION_DIR and it will keep working. But you will not benefit from the new features (DESTDIR, installation in Unix FHS). So, if you're not interested in the new features, there are no changes, everything that used to work will still keep working. If you are and/or might ever be interested in the new features, I recommend you switch to using GNUSTEP_INSTALLATION_DOMAIN (this is a tiny change). Since software authors usually are keen to see their software being as deployable as possible in all sorts of situations, I strongly recommend you switch. * Agreeing on the guidelines for setting the default GNUSTEP_INSTALLATION_DOMAIN of software. All software that we (GNUstep project) manage directly will of course be changed to comply with the guidelines, but that change (if there is a change) will be silent to you as a user, ie nothing should be broken by it. Worst case is some libraries or tools will be moved from one domain to the other one; you can still link to them or invoke them in the same way though. You are free to change your software to comply with our guidelines or not; we can't force you. The software will still work if you don't comply. ;-) But I recommend you switch to the guidelines, once we have them, so that users can expect a consistent behaviour from all GNUstep stuff. :-) > It was difficult enough adapting to the round of changes when > GNUstep.conf was introduced, and I daresay there is still confusion > amongst app developers as to the respective roles of GNUstep.conf and > GNUstep.[c]sh. While the benefits of FHS installation are nonzero, > the amount of initial disruption and any possible divergence in OS X > compatibility should be carefully considered. I understand the confusion, and also the doubts about further changes. ;-) Part of the reason is that we haven't really provided any real benefits/simplifications to end users yet. We have been changing things, as part of our long-term strategy, but we have yet to deliver any real benefits! That must be frustrating for users. I mean, you still have to source GNUstep.sh in the latest stable release and all still works in the same way ;-) But finally in the new release we'll have new powerful options that let you integrate your GNUstep installation very strictly with the native system. It will be my pleasure to write detailed documentation on all that. :-) At that point the benefits will be very clear ... so months/years of discussions and work on GNUstep.conf and other general reorganizations (by me, Richard, and everyone else involved) will finally produce the 'native integration' option that is so key and cool. ;-) And that without sacrificing any of the existing functionality ... which is not trivial at all. Hopefully at that point the reason for all the changes will be more clear. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev