GNUSTEP_INSTALLATION_DOMAIN

[Nicola Pero]

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

[Nicola Pero]

> 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

[Richard Frith-Macdonald]

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

[Dennis Leeuw]

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

[Nicola Pero]

> 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

[Nicola Pero]

> 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

[David Ayers]

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

[Richard Frith-Macdonald]

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

[Nicola Pero]

> 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

[Nicola Pero]

> 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

[Adam Fedor]

> -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

[Richard Frith-Macdonald]

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

[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






___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUSTEP_INSTALLATION_DOMAIN

[Hubert Chan]

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

[Richard Frith-Macdonald]

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

[David Ayers]

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

[Richard Frith-Macdonald]

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

[Sheldon Gill]

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

[Nicola Pero]

> 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

[Nicola Pero]

>>> 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

[Nicola Pero]

>> 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

[Sheldon Gill]

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

[Nicola Pero]

>> 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

[Richard Frith-Macdonald]

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

[Richard Frith-Macdonald]

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

[Hubert Chan]

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

[Richard Frith-Macdonald]

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

[Richard Frith-Macdonald]

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

[Adrian Robert]

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

[Nicola Pero]

> 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