mingw installation domains: system vs. local defaults!
Hi, Fred's question about me having multiple base installation proved to be legitimate. I discovered that I have gnustep-base in both the local domain and in the system domain on windows. The new one, the current one, being in Local and the old one in System, about from March. This explains also the message source file newer than executable. it was not referred to Ink, but to the library. However, I never changed installation domains and I still have in /etc/GNUstep/installation-domain.conf all system libraries in SYSTEM. I do not specify during configure and make time the installation domain. Are we back to the nightmare were we need to specify the installation domain manually on windows? I truly hope NOT! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installation domains
On Wed, 29 Oct 2008 18:26:13 +, Richard Frith-Macdonald [EMAIL PROTECTED] said: Tentative policy and development proposals ... please enhance and then we can see if we can agree on the way forward. 1. We will move to FHS as the default layout for new installations [...] FWIW, IMHO, I don't think that GNUstep should default to FHS by default. While FHS support is handy for distributions like Debian that insist on everything following the FHS (and even then, we were getting by, just using symlinks to fake the whole thing), I think that it is best to keep the GNUstep layout by default. (And in fact, one of my goals is to eventually get a set of Debian packages that follows the GNUstep layout rather than FHS.) Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installation domains
Hi, things are starting to delineate and I think there are good ideas floating around. I am mainly concerned with the defaults, which I'd like to keep as is. Some comments below. On 2008-10-29 22:32:17 +0100 Nicola Pero [EMAIL PROTECTED] wrote: 1. we install by default gnustep-make (and hence, GNUstep) into /usr/ local/GNUstep instead of /usr/GNUstep. To avoid breaking things too much, we could detect if there is already an installation in /usr/GNUstep and in that case print a big warning and explain that you need to use --prefix=/usr/GNUstep to get the old behaviour. I think this is essentially useless. /usr/GNUstep is fine for me. Those who package or have the knowledge that they want to fine tune their install, like directly into /, /usr, /usr/local or /opt (examples)... will have the knowledge to read the manuals, the wiki, whatever. Those who do not understand, shouldn't even compile: they should (and most probably will) pull packages from their distribution and there the packager will have done the work. 4. we add support in gnustep-make for a new variable, something like GNUSTEP_CORE_PACKAGE=YES, which causes it to install into System by default, instead of Local as long as it stays by default to SYSTEM, it is fine. THis is actually needed for what I write below. 5. we add a new option to gnustep-make's ./configure, something like ./ configure --install-core-packages-into=local, which can be used to change where stuff with GNUSTEP_CORE_PACKAGE=YES is installed by default. We default to System but suggest that packagers packaging gnustep-make change it to default to Local instead when shipping gnustep-make Yes. as in 4. I tink this is most useful for FHS. 6. we do a gnustep-make release, then wait 6 months or so, then we change all GNUmakefiles in devmodules that currently have GNUSTEP_INSTALLATION_DOMAIN=SYSTEM to instead have GNUSTEP_CORE_PACKAGE=YES Thus the result... would be the same. The only real visible change for people compiling everything from source would be 1., from /usr/GNUstep to /usr/local/GNUstep, but the new ./configure options would allow packagers to ship a better setup. I'd even avoid that change, for the reasons above. Let me sum up. We have mainly two install scenarios corssed by three user scenarios install: A: standard GNUstep layout with some kind of prefix (/usr/GNUstep being currently the default) B: FHS layout usage: 1. packages 2. self compilation of everything 3. self compilation of some applications A2 is what we currently do. I think nothing should change. I expect system stuff to go into system, local stuff into local. This mimicks, once compiled, that it looks like a supplied OS, say Apple or OpenStep B2: there i think your new flag about CORE PACKAGE comes handy, before your idea I was oging to complain about that: OS-supplied packages co, for example, all in /usr and should ignore our system and local distinction. Thus from the packagers point of view SYSTEM and LOCAL domain should be the same: if a packager supplies FTP.app it should go into the same plabe as GWorkspace.app or SystemPreferences.app. That is, usually, /usr/bin A1, B1: be it A or B, it is at the packagers choice, there should be no problem at all, he is capable of passing the flags to configure, once documented well 3A, 3B: as long as the user compiles new applications, everything goes into the LOCAL domain as expected (for FHS, /usr/local). The scenario is that the installs all the core stuff and then, for example, pulls FTP.app and decides to install it himself. there are two problem which are on the border though. p1. GNUstep doesn't support multiple instances of the same application. this affects the B (FHS) scenario mostly. A user gets the core stuff by packages, everything is into /usr. He installs FTP from a package. gets into /usr. He now compiles a newer FTP from sources, according to FHS logic it should go into /usr/local. (this is standard today: on my solaris box I have the stanard tar and the gnu tar...) but make_services would complain for a double installed app p2. the developer. He installs everything from source, typically in scenario A (that's me...). I want system stuff to be in /System and my own stuff into /Local. ANd I should be able to recompile the system stuff as many times I want. problem 2 currently doesn't exist: it just works that way, but I fear it could break problem 1 currenty doesn't exist since everything behaves like 2. I don't understand how you can distinguish between package supplied stuff and user compiled stuff with a single make-system. On the other hand I agree with you that if something is in /usr it shouldn't be deliberately replaced by the stuff compiled by a user. So I would accept a compromise where you install a package, compile your own version, get an error and need to remove the package. So, after this long summary, a possibility would be:
installation domains
Tentative policy and development proposals ... please enhance and then we can see if we can agree on the way forward. 1. We will move to FHS as the default layout for new installations 2. We will retain backward compatibility for existing installations (at least for a year or two) To maintain backward compatibility, the current 'system' applications will need to remain as such when installed into an existing system. That means they need to carry on to have GNUSTEP_INSTALLATION_DOMAIN defined as SYSTEM in their makefiles (or be changed to use another name, but if we do that we need to synchronise the change with a gnustep-make change, so it's probably easier to leave them unchanged). 3. gnustep-make needs to be changed to: a. continue to honor GNUSTEP_INSTALLATION_DOMAIN in the makefiles if it is installing on an existing system using old-style locations. b. ignore GNUSTEP_INSTALLATION_DOMAIN in makefiles if it is installing into a new system or a system already using a non-gnustep style layout. 4. gnustep-make should probably also warn about the consequences of the layout selected 5. documentation should be updated to use FHS style layout in all examples. Does that cover it? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installation domains
Hi, On 2008-10-29 19:26:13 +0100 Richard Frith-Macdonald [EMAIL PROTECTED] wrote: Tentative policy and development proposals ... please enhance and then we can see if we can agree on the way forward. 1. We will move to FHS as the default layout for new installations I raise my hand against FHS as a default. While I am in favour of a compelte support for it at the choice of any packager with just a flag in gnustep-make, it should not be the default. I remember to everybody that the best possible would be to have /---root +---Local +---System +---Applications +---Library +---Network and so on. The next less-native version is to have root be placed anywhere. I still think /usr/GNUstep is a good choice, self contained and clean, following the example of many classics. /usr/local/GNUstep or /opt/GNUstep being two other classic options. configure --prefix=/ configure --prefix=/opt/GNUstep just at your fingertips. FHS support is good for those who strive for the standard and thus shall be supported, but it is not what we should offer by default. Sorry. my personal 2 cents. Riccaardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installation domains
Tentative policy and development proposals ... Thanks - here is the tentative policy I was thinking of (we can presumably merge the two in some way to move forward) from the suggestions that have been put forward -- 1. we install by default gnustep-make (and hence, GNUstep) into /usr/ local/GNUstep instead of /usr/GNUstep. To avoid breaking things too much, we could detect if there is already an installation in /usr/GNUstep and in that case print a big warning and explain that you need to use --prefix=/usr/GNUstep to get the old behaviour. 2. we add an option to gnustep-make's ./configure to install gnustep- config, openapp and opentool in a different directory (if nothing's specified, we install them into SYSTEM_TOOLS as we do now) 3. we change gnustep-make's configure to print out some useful message on the chosen filesystem layout (and how to use it) at the end 4. we add support in gnustep-make for a new variable, something like GNUSTEP_CORE_PACKAGE=YES, which causes it to install into System by default, instead of Local 5. we add a new option to gnustep-make's ./configure, something like ./ configure --install-core-packages-into=local, which can be used to change where stuff with GNUSTEP_CORE_PACKAGE=YES is installed by default. We default to System but suggest that packagers packaging gnustep-make change it to default to Local instead when shipping gnustep-make 6. we do a gnustep-make release, then wait 6 months or so, then we change all GNUmakefiles in devmodules that currently have GNUSTEP_INSTALLATION_DOMAIN=SYSTEM to instead have GNUSTEP_CORE_PACKAGE=YES The only real visible change for people compiling everything from source would be 1., from /usr/GNUstep to /usr/local/GNUstep, but the new ./configure options would allow packagers to ship a better setup. Your tentative policy is much more aggressive ... in that it suggests moving to FHS by default. I don't really have an opinion on that - I'm happy to do it, but I'm also happy to keep our current GNUstep layout. I think FHS will appeal to GNU/Linux users, and the GNUstep layout will appeal to users from the Apple world. Not sure who would be compiling from source the most. ;-) More suggestions/comments welcome. Thanks please enhance and then we can see if we can agree on the way forward. 1. We will move to FHS as the default layout for new installations 2. We will retain backward compatibility for existing installations (at least for a year or two) To maintain backward compatibility, the current 'system' applications will need to remain as such when installed into an existing system. That means they need to carry on to have GNUSTEP_INSTALLATION_DOMAIN defined as SYSTEM in their makefiles (or be changed to use another name, but if we do that we need to synchronise the change with a gnustep-make change, so it's probably easier to leave them unchanged). 3. gnustep-make needs to be changed to: a. continue to honor GNUSTEP_INSTALLATION_DOMAIN in the makefiles if it is installing on an existing system using old-style locations. b. ignore GNUSTEP_INSTALLATION_DOMAIN in makefiles if it is installing into a new system or a system already using a non-gnustep style layout. 4. gnustep-make should probably also warn about the consequences of the layout selected 5. documentation should be updated to use FHS style layout in all examples. Does that cover it? ___ 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
