[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #13, bug #30470 (project gnustep): >> 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

[bug #30474] obsolete environment still set by default ... shouldn't be

Follow-up Comment #2, bug #30474 (project gnustep): In base I use a rule of a complete release cycle (excluding bugfix releases). ie if something is deprecated in one release, it has to continue to exist until the next release. Since we actually tend to do non-bugfix releases about once a year,

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #12, bug #30470 (project gnustep): 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. ___ Reply to this it

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #11, bug #30470 (project gnustep): > 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 diff

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #10, bug #30470 (project gnustep): 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 t

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #9, bug #30470 (project gnustep): > 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-specifi

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #8, bug #30470 (project gnustep): 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/L

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #7, bug #30470 (project gnustep): > 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 relati

[bug #30474] obsolete environment still set by default ... shouldn't be

Follow-up Comment #1, bug #30474 (project gnustep): We generally wait 5 years. The variables don't actually cause any harm - the 'GNUSTEP' prefix makes sure they don't interfere with anything. So I guess I'd wait another couple of years. ;-) Thanks

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #6, bug #30470 (project gnustep): > 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 h

[bug #30474] obsolete environment still set by default ... shouldn't be

URL: Summary: obsolete environment still set by default ... shouldn't be Project: GNUstep Submitted by: CaS Submitted on: Sun 18 Jul 2010 05:04:43 PM GMT Category: Makefiles

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #5, bug #30470 (project gnustep): 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 v

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #4, bug #30470 (project gnustep): 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

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #3, bug #30470 (project gnustep): 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 it

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Follow-up Comment #2, bug #30470 (project gnustep): 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 aft

[bug #30470] GNUSTEP_USER_ROOT and GNUSTEP_PATHLIST set to wrong value

Update of bug #30470 (project gnustep): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: GNUSTEP_USER_ROOT