Re: GNUSTEP_INSTALLATION_DOMAIN

[Nicola Pero]

> 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