[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUstep-packagers] patch for observance of $HOME
From: |
Richard Frith-Macdonald |
Subject: |
Re: [GNUstep-packagers] patch for observance of $HOME |
Date: |
Sat, 7 Aug 2004 10:58:07 +0100 |
On 7 Aug 2004, at 10:20, Sheldon Gill wrote:
On Sat, 7 Aug 2004 16:24, Richard Frith-Macdonald wrote:
On 7 Aug 2004, at 08:13, Sheldon Gill wrote:
On Fri, 6 Aug 2004 22:26, Armando Di Cianno wrote:
On 2004-08-06 04:36:01 -0400 Richard Frith-Macdonald
<richard@brainstorm.co.uk> wrote:
[snip]
I would not use such a system ... it's a strong requirement for
rolling
out systems
for clients that the installed system be relocatable as I don't
necessarily know
where the client is going to install the software. It's no use having
my software
relocatable if the gnustep package I bundle with it depends on
hard-coded paths.
If you choose not to use this element of the system, that's fine. (0)
uses the
environment variables. So it's not different to the current situation.
Note also that although the startup file is in a chosen location, the
actual
binary installation can go anywhere. The startup file is a
configuration
file which has a well defined place to live on pretty much all
POSIX-ish
systems. Exactly where varies from OS to OS but that isn't so much of
an
issue. You can have the client install the software where ever they
want,
they just need to put the .conf file in one place. Same as currently
done
with a multitude of other *nix software.
As long as the location of the startup file is not fixed at build time,
it's fine to use a startup file (in fact my preferred option).
It's also good to have a standard location defined at build time, as
long as one is not forced to use it.
eg. The startup logic could run -
1. Try configured startup location... use it if present otherwise ...
2. Look for environment variable defining location of startup file.
That way, on a system where you have root access, you can create
a startup file in the standard location, thus *forcing* all users of
GNUstep
to use the information you supplied.
On the other hand, where you don't have root access, you can set an
environment variable to specify the location of your own GNUstep
installation, as long as root has not put an overriding startup file in
place.
The (2) defaults are, again, set during the build phase. There is
even
provision for the library to be built to go straight to (2), ie use
hard-code
only. That is a good choice for a package on a fixed FS layout.
Under such
a system there is only one place for things to go and so no decisions
really
need to be made.
But with clients who require easy to install relocatable binary
packages,
this scheme is no good at all ... as usual, a solution which is ideal
for one purpose
can easily be unusable for another.
That's true. That is why there is a multi-step approach and why I've
included
additional build time configuration options. Choose the right scheme
for your
application.
I haven't looked at these details but ... my preference would be for a
scheme
with *NO* build time configuration options to be set. This is to say,
it would
be best to have things work the same way on all systems and to have that
one way be both simple and flexible enough to cover all requirements.
We also
need to modify PATH and LD_LIBRARY_PATH etc to allow GNUstep
programs
to be
simply run from the unix shell.
[Snip]
Yes ... but we need to provide a script to make the job easy for
people
who
aren;t using pre-packaged installations where the job is done for
them.
Sure. I was pointing out some options with intention of highlighting
flexibility. Not advocating forcing everyone to pre-packaged
installations at
all. I do think, though, that pre-packaged will become the majority of
installations in time. That's been the case with lots of other
software.
many ways to configure the GNUstep env in subtle ways is, well, a
[Snip]
I think the whole issue is easily solvable (as I mentioned in an
earlier post) by
having a single environment variable to define the root of the GNUstep
installation
and having make and base deduce all other information from that.
I disagree on this. From a security and administrative view this
isn't an
acceptable solution for many installations.
I'm not sure why you think this ... on a system where the administrator
wants to have users locked down, s/he would control this by having the
top level .GNUsteprc file override the default so providing complete
control over the users, and on a system where users control their own
GNUstep installations, the environment variable is secure ... unless
someone has hacked in to their account or got them to run a trojan ...
in which case all security for that user is already compromised.
- Re: [GNUstep-packagers] patch for observance of $HOME, Adam Fedor, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Matt Rice, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio Serrano, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Armando Di Cianno, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME,
Richard Frith-Macdonald <=
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio Serrano, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/08
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/08
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/10
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Armando Di Cianno, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/06