bugGNUstep - Bugs: bug #30470, GNUSTEP_USER_ROOT and...

Group
 
 

bug #30470: GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Submitter:  Derek Fawcus <dfawcus>
Submitted:  Sun 18 Jul 2010 06:54:29 AM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 22 Mar 2011 03:19:05 PM UTC, comment #15: 

Ok, I implemented this for gnustep-make as well.

Thanks

Nicola Pero <nico>
Group Member
Mon 19 Jul 2010 09:01:59 AM UTC, comment #14: 

I added that for gnustep-base (a config value which resolves to an absolute path is now treated as such rather than being treated as relative to the user's home directory).

I also added support for '%u' (username), '%i' (user ID), and '%%' (escape  percent) when processing user domain config values.

Richard Frith-Macdonald <CaS>
Group Member
Sun 18 Jul 2010 10:03:37 PM UTC, comment #13: 


>> We actually have (or are supposed to have!) support for an
>> absolute path for user domain locations.
>
>
> Not afaik ... I believe the user domain locations are always
> taken relative to the user's home directory. Of course,
> gnustep-make may differ from gnustep-base behavior.


Yes, it is implemented in gnustep-make.

You are right that it is not implemented in gnustep-base ... may be worth doing it. :-)

Thanks

Nicola Pero <nico>
Group Member
Sun 18 Jul 2010 08:58:45 PM UTC, comment #12: 

Of course, adding support for treating paths in the USER domain which begin with a slash as NOT being relative to the home directory would be an easy change to make.

Richard Frith-Macdonald <CaS>
Group Member
Sun 18 Jul 2010 07:52:35 PM UTC, comment #11: 


> We actually have (or are supposed to have!) support for an absolute
> path for user domain locations.


Not afaik ... I believe the user domain locations are always taken relative to the user's home directory.  Of course, gnustep-make may differ from gnustep-base behavior.

Richard Frith-Macdonald <CaS>
Group Member
Sun 18 Jul 2010 07:23:14 PM UTC, comment #10: 

Sorry for posting again, just wanted to make sure people searching for this topic find updated information --

> I can see a case for extending this, but it's not clear how:
> Perhaps just to disable the USER domain entirely.
> Perhaps to map the USER domain to another domain.
> Perhaps to make the USER domain a shared domain (like LOCAL or
> NETWORK).


As far as I know (please correct me if I'm wrong) you can specify an absolute path for a user domain path, which means you can do all the above --

  • disable the USER domain entirely (by using the same paths used for NETWORK, so that it is collapsed with NETWORK, and it no longer does anything)


  • map the USER domain to another domain (same technique)


  • make the USER domain a shared domain (just use absolute path for the USER domain, but different from the ones used by other domains)


The one we miss at the time of writing is the last one --

  • Perhaps to make the USER domain be in a per-user area relative to some other location ... but if so, how would we specify it? I'm not sure was could do it by username as a username may not be a valid file name. Probably we could put it in a directory referenced by user ID (afaik all operating systems provide some sort of numeric user ID).


We don't support this, but if we do, I like having a couple of placeholders such as %u for the username and maybe another one for the user id ?

Thanks

Nicola Pero <nico>
Group Member
Sun 18 Jul 2010 07:18:33 PM UTC, comment #9: 


> And the current support is only for locations relative to the
> user's home directory.


We actually have (or are supposed to have!) support for an absolute path for user domain locations.  That means the user domain is no longer user-specific, ie, it becomes yet another system-wide user domain.  It could be collapsed with the local domain, for example, effectively disabling the user domain.  Or it could be used as yet another system-wide user domain.

We clearly don't have the ability, to, say, have a user domain path in /GS/{username}/Tools/.  If we do, we could follow the convention that OpenSSH uses in sshd.conf for AuthorizedKeyFiles:

"The following tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated and %u is replaced by the username of that user." (from the sshd.conf manpage)

Clearly, we wouldn't follow it literally, eg, we wouldn't have %h which is implicitly and automatically already added at the beginning if the path is relative.  But we could use %% and %u.

That probably shouldn't be too difficult to implement.

Thanks

Nicola Pero <nico>
Group Member
Sun 18 Jul 2010 07:12:01 PM UTC, comment #8: 

By the way, to clarify, the issue has nothing to do with old or new variables (Richard was right in creating a separate issue for that). ;-)

For example, Derek's LD_LIBRARY_PATH is set to:

LD_LIBRARY_PATH=/home/derek/GS/Library/Libraries:/GS/Local/Library/Libraries:/GS/Network/Library/Libraries:/GS/System/Library/Libraries

this clearly means that GNUSTEP_USER_LIBRARIES is /home/derek/GS/Library/Libraries, which doesn't sound like what Derek wants.

If the idea is not conflicting with an existing GNUstep from a Linux distribution, it sounds fine to me though! ;-)

Thanks

Nicola Pero <nico>
Group Member
Sun 18 Jul 2010 07:08:40 PM UTC, comment #7: 


> I believe I attached the rejigue file to the bug.


Thanks - I now found it. :-)

In your filesystem layout file, you have, for example,

GNUSTEP_USER_DIR_TOOLS=GS/Tools

because this path is relative, it is automatically assumed to be relative to the user home dir.  By the way, that should still satisfy your requirements; while the standard GNUstep installation from the distribution will (most likely) be using ~/GNUstep/Tools, your installation will be using ~/GS/Tools, so there is no conflict there - different directories are used to put stuff in! :-)

If you still want to use /GS/Tools for all users, it should be as simple as making the directory path absolute --

GNUSTEP_USER_DIR_TOOLS=/GS/Tools

that should tell both gnustep-make and gnustep-base that the directory is a fixed, absolute directory, not relative to the user's home directory. :-)

Unfortunately, you then have to store the user's defaults somewhere.  You most likely don't want different users to share the user default.  Presumably you could leave that one as

GNUSTEP_USER_DEFAULTS_DIR=GS/Defaults

again, that actually means ~/GS/Defaults.

Thanks

Nicola Pero <nico>
Group Member
Sun 18 Jul 2010 05:12:04 PM UTC, comment #6: 


> Are you suggesting it was impossible to configure the ~/GNUstep directory to have a different name under the version this is supposed to provide compatibility with?


Yes.

And the current support is only for locations relative to the user's home directory.
I can see a case for extending this, but it's not clear how:
Perhaps just to disable the USER domain entirely.
Perhaps to map the USER domain to another domain.
Perhaps to make the USER domain a shared domain (like LOCAL or NETWORK).
Perhaps to make the USER domain be in a per-user area relative to some other location ... but if so, how would we specify it?  I'm not sure was could do it by username as a username may not be a valid file name.  Probably we could put it in a directory referenced by user ID (afaik all operating systems provide some sort of numeric user ID).

Richard Frith-Macdonald <CaS>
Group Member
Sun 18 Jul 2010 04:59:43 PM UTC, comment #5: 

How are they valid?

Are you suggesting it was impossible to configure the ~/GNUstep directory to have a different name under the version this is supposed to provide compatibility with?

anyway - I guess this is moot if configuring with strict v2 mode will ensure the variables are not set,  and not referenced.

Derek Fawcus <dfawcus>
Sun 18 Jul 2010 04:31:48 PM UTC, comment #4: 

The environment variables are NOT set to invalid values ... they are the correct values for backward compatibility (ie the values which would have existed in an old version of GNUstep).

If you have old code which uses the environment variables (you shouldn't), then it will continue to function the way it always did.
If you have new code, it should not use those environment variables, so their values are irrelevant to it.

Probably more importantly ... the GNUstep configuration system does not support what you seem to want to do ... the 'USER' domain layout is relative to the home directory of the user, and there is no way to change that.

Richard Frith-Macdonald <CaS>
Group Member
Sun 18 Jul 2010 02:14:53 PM UTC, comment #3: 

The issue is why the environment variables were set to invalid values,  not why they were set at all.  Given that they were set,  and the values are invalid,  what impact will they then have.

I guess I could try the strict mode,  but even in its absense the fact the the 'compatibility' variables have invalid values does not seem to be sensible.

my requested environment values,  before and after sourcing the config file:

h=net$; env|grep PATH
NLSPATH=/usr/share/locale/%l/%N
PATH=/home/derek/scripts:/home/derek/bin:/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/opt/real/RealPlayer:/opt/real/RealPlayer:/usr/lib/ssh:/opt/real/RealPlayer:/opt/real/RealPlayer
PYTHONPATH=/usr/lib/ooo/basis-link/program:/usr/lib/ooo/basis-link/program:/usr/lib/ooo/basis-link/program:/usr/lib/ooo/basis-link/program
WINDOWPATH=7

h=net$; . /GS/System/Library/Makefiles/GNUstep.sh
h=net$; env|grep PATH
LD_LIBRARY_PATH=/home/derek/GS/Library/Libraries:/GS/Local/Library/Libraries:/GS/Network/Library/Libraries:/GS/System/Library/Libraries
GUILE_LOAD_PATH=/home/derek/GS/Library/Libraries/Guile:/GS/Local/Library/Libraries/Guile:/GS/Network/Library/Libraries/Guile:/GS/System/Library/Libraries/Guile
NLSPATH=/usr/share/locale/%l/%N
PATH=/home/derek/GS/Tools:/GS/Local/Tools:/GS/Network/Tools:/GS/System/Tools:/home/derek/scripts:/home/derek/bin:/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/opt/real/RealPlayer:/opt/real/RealPlayer:/usr/lib/ssh:/opt/real/RealPlayer:/opt/real/RealPlayer
PYTHONPATH=/usr/lib/ooo/basis-link/program:/usr/lib/ooo/basis-link/program:/usr/lib/ooo/basis-link/program:/usr/lib/ooo/basis-link/program
GNUSTEP_PATHLIST=/GS/System:/GS/Network:/GS/Local:/home/derek/GNUstep
CLASSPATH=/GS/System/Library/Libraries/Java:/GS/Network/Library/Libraries/Java:/GS/Local/Library/Libraries/Java:/home/derek/GS/Library/Libraries/Java
INFOPATH=/GS/System/Library/Documentation/info::/GS/Network/Library/Documentation/info::/GS/Local/Library/Documentation/info::/home/derek/GS/Library/Documentation/info:
WINDOWPATH=7

I believe I attached the rejigue file to the bug.
I wanted the USER domain to exist under either /GS/User/GS/... (one for all users) or under /GS/user/<username>/GS/...;  as to which resulted,  I didn't care.

Hence setting 'GNUSTEP_LOCAL_USERS_DIR=/GS/Users' was a bit of an experiment.

AS to my overall aim,  to have a complete parallel install of GNUstep alongside the copy provided by the distribution,  and for neither to interfer with the other.  Hence why there reference to the ~/GNUstep directory (which already exists due to the distribution installation) is of concern.

Oh - and BTW this is a view over 'make/trunk@30836'.

Derek Fawcus <dfawcus>
Sun 18 Jul 2010 10:02:24 AM UTC, comment #2: 

Richard is right. :-)

But I wonder if Derek may still be having a valid problem with other variarbles, which is hard to say without more information ;-)

Derek, can you include the full output of

env | grep PATH
env | grep LD_LIBRARY_PATH

after sourcing GNUstep.sh ?  Just to check that PATH and LD_LIBRARY_PATH are set correctly.

If they are not set correctly, can you share the "rejique" layout with us ?  Can you also explain what you are trying to set up ?  where do you want the GNUstep user stuff (eg, Libraries, etc) to reside exactly ?

At the moment, IIRC there are two ways you can configure the user GNUstep directories (eg, GNUSTEP_USER_TOOLS etc):

  • each person would have his own as a subdirectory of their home directory; eg, most layouts supplied with gnustep-make use GNUSTEP_USER_TOOLS=~/GNUstep/Tools (please that the "~" is not included in the filesystem file, so eg, in core/make/FilesystemLayout/gnustep you have GNUSTEP_USER_TOOLS=GNUstep/Tools, and the "~/" is added automatically because GNUSTEP_USER_TOOLS is relative)


  • a single user GNUstep directory for everyone (basically disabling it as a personalized directory); this is obtained by using an absolute path in the filesystem layout (eg, GNUSTEP_USER_TOOLS=/GS/Network in the filesystem layout file would effectively collapse the User and Network tools directory - note that "~/" is not added because the path is already absolute).  In this case, basically GNUstep users can't install their own apps/frameworks/libraries/tools in their own personal directories, so the GNUstep User domain just becomes another system-wide domain.


If you want each user to have his own GNUstep user directory, but outside of their own home directory, there is currently no way of doing it (eg, if you want /GS/User/derek/Tools to be your GNUSTEP_USER_TOOLS, while another user would have /GS/User/{username}/Tools).  The theory is that this would be possible by changing the GNUSTEP_HOME variable, but at the moment that variable is always set to "~".  I guess if it's important, we could finish the implementation and allow you to somehow set GNUSTEP_HOME to something different (this requires synchronized changes to gnustep-make and gnustep-base).  One problem with this approach is that while the home directory normally exists and is owned and writable by the user, there is no guarantee that /GS/User/{username}/ actually exist and is owned by the user, so it would most likely simply not work in practice unless it's a GNUstep-based OS where these directories are automatically created etc.

Let me know if this helps :-)

Thanks

Nicola Pero <nico>
Group Member
Sun 18 Jul 2010 07:22:37 AM UTC, comment #1: 

GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST were deprecated in early 2007 and available only in backward compatibility mode since early 2008.

In terms of backward compatibility, the behavior you are seeing looks correct.

You should configure gnustep-make with --enable-strict-v2-mode to get rid of backward compatibility environment variables.

Try 'configure --help' for more information.

Richard Frith-Macdonald <CaS>
Group Member
Sun 18 Jul 2010 06:54:29 AM UTC, original submission:  

make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
With a file system layout intended to move everything to a hieraracy under /GS,  and with a set of USER domain paths being relative to GS,  the effect of sourcing GNUstep.sh is to polluted with a user directory that still references the GNUstep directory under the home directory.

./configure --with-layout=rejigue --with-config-file=/GS/System/etc/GNUstep.conf --with-user-config-file=GS/GNUstep.conf --enable-native-objc-exceptions

(as root):
make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM

(as user):
h=net$; env|grep GNUSTEP
h=net$; . /GS/System/Library/Makefiles/GNUstep.sh
h=net$; env|grep GNUSTEP
GNUSTEP_IS_FLATTENED=yes
GNUSTEP_LOCAL_ROOT=/GS/Local
GNUSTEP_HOST=i686-pc-linux-gnu
GNUSTEP_MAKEFILES=/GS/System/Library/Makefiles
GNUSTEP_NETWORK_ROOT=/GS/Network
GNUSTEP_FLATTENED=yes
GNUSTEP_HOST_OS=linux-gnu
GNUSTEP_HOST_VENDOR=pc
GNUSTEP_HOST_CPU=ix86
GNUSTEP_USER_ROOT=/home/derek/GNUstep
GNUSTEP_SYSTEM_ROOT=/GS/System
GNUSTEP_PATHLIST=/GS/System:/GS/Network:/GS/Local:/home/derek/GNUstep

h=net$; echo $HOME
/home/derek

The same results even if the (obsolete) config option '--with-user-dir=GS' is added.


Derek Fawcus <dfawcus>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #20998:  rejigue added by dfawcus (3KiB - application/octet-stream - The custom file system layout used)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nico (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by dfawcus (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-18 CaS StatusNone Invalid
        Open/ClosedOpen Closed
    2010-07-18 dfawcus Attached File- Added rejigue, #20998

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code