[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian and SimplyGNUstep

From: oberhage
Subject: Re: Debian and SimplyGNUstep
Date: 13 Oct 2003 09:20:29 GMT
User-agent: tin/1.4.6-20020816 ("Aerials") (UNIX) (AIX/5-1)

Jeff Teunissen <address@hidden> wrote:
: address@hidden wrote:

:> aren't, you/we can add this to GNUSTEP_ROOT, such that there is
:> e.g. Net(work) within /usr/lib/GNUSTEP (for Debian) and so link
:> /Net(worK) to that - apart from /System, where this applies naturally.

: GNUSTEP_ROOT is going away.

So, I didn't know! How come? Or is it just replaced by something else?

: I also am not sure whether or not automatically placing symlinks in / is
: "legal" according to Policy -- in fact, I believe it is not.

Not sure about 'automatically' in the sense of 'non-asking'; but e.g.
the Debian kernel-packages offer to make symlinks for the "inital ramdisk"
if there aren't any. So at least for Debian, this seems to be ok - if
you ask the admin politely :-) and give him the choice to deny.

:> [...]
:> Even the point with the .hidden-file having to reside in the '/'
:> directory is not totally true.

: Yes, it _is_ totally true. There is no single .hidden file; there is one for
: each directory in which special pathnames should be hidden for non-"UNIX
: Expert"s. /.hidden only hides paths in the root directory. For hidden files
: to work properly, they basically have to be handled at the distribution
: level.

May be I didn't make my point clear enough: Yes, '.hidden' works as you
say (hey, I'm still writing this on an OPENSTEP machine, here :-)), but
apart from .hidden, there are other mechanisms, as e.g. the one which
disables 'per user for the user' to see /tmp, /bin etc. on a more 'global'
basis. So if one doesn't like a .hidden in '/' (and I'm not so sure if
I would like it on my systems), you can have another file on a per user
basis. This is all I meant with the 'having to reside ... not totally true'.
When you take that verbatim with the .hidden, yes you're right. What I meant
was that it is not the only way to handle this. Sorry for the misleading

: [snip]

:> The last point: Debian (and I'm just talking 'woody' here), in contrast
:> to what another person posted previously,  has a very well developed
:> concept to allow 'display managers' to enter window-sessions like 'kde',
:> 'gnome' or 'wmaker' (well, the latter just parlty a session :-).

: Let me say that I'm a Debian developer, and that as far as I know, I
: basically drafted the first /etc/Xsession.d system in 1999, so I know how it
: works. :)

So you know how hard it is - since woody - to have a person log-in into
'wmaker' by default for the first time, once you have a "session"-thing
installed (as 'kde' or 'gnome-session') :-), even if the 'alternatives'
list 'wmaker' as the preferred window-manager(!) choice. A 'wmaker'
"session counterpart" would be very welcome, and this could easily be a
GNUstep one. Since you're a Debian developer, you might introduce it ... :-)

Thanks and greetings,
H.-R. Oberhage
Mail: Univ. Duisburg-Essen              E-Mail: address@hidden
      Fachbereich 7 (Physik)                   address@hidden
      Standort Essen, S05 V07 E88
      Universitaetsstrasse 5            Phone:  (+49) 201 / 183-2493
      45141 Essen, Germany              FAX:    (+49) 201 / 183-4578

reply via email to

[Prev in Thread] Current Thread [Next in Thread]