> 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 [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
