Glenn Bily <[EMAIL PROTECTED]> writes:
> Folks,
> [This should spark a debate :)]
>
> What is the fine line between a library such as libc.so.5, libm.so.5 or
> libcurses.a and just a compiled object file?
Please do not try to "spark debate" (troll) on the FHS discussion
mailing list. I do not ap
Folks,
[This should spark a debate :)]
What is the fine line between a library such as libc.so.5, libm.so.5 or
libcurses.a and just a compiled object file?
--Glenn
Larry,
They intend to implement /opt as a major mount point. They also plan to
make /usr/local a very dangerous place to play. :)
I hope that Debian will make a policy of staying out of /usr/local.
This is way it is shaping up for each application:
Beside the binary in /usr/bin or /bin.
There wi
Greg Hudson writes:
-> >> In addition, the admin's life would only be made easier.
->
-> > "Let's see where is perl stuffof course: /usr/perl"
->
-> Of course it looks easier if you only ask one question.
->
-> "Where are the operating system binaries that should go in users'
-> paths?"
->
On Wed, 4 Sep 1996, Philippe Troin wrote:
> On Wed, 04 Sep 1996 11:04:06 CDT David Engel ([EMAIL PROTECTED])
> wrote:
> > There is a curses-based version of Tk, but I don't have any idea of
> > how well it works.
>
> Do you know where we could find this thing ? Might be interesting...
It's at
ft
On Wed, 04 Sep 1996 11:04:06 CDT David Engel ([EMAIL PROTECTED])
wrote:
> Bruce Perens writes:
> > It's unfortunate that the printer config stuff (and other stuff from
> > Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the
> > user has X (or even a VGA card - it might be a se
> Your idea is sound. I'm opposed to merging XDM and startx too much. XDM
> and startx already share too much to some degree. We need to make
> considerations that someone running XDM will not necessarily have
> choices of window managers before the session begins. It would be a big
> plus if Debi
Bruce Perens writes:
> It's unfortunate that the printer config stuff (and other stuff from
> Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the
> user has X (or even a VGA card - it might be a serial console).
>
> A shell/dialog solution would be much better.
There is a curse
> Jason,
> On Sun, 1 Sep 1996, Glenn Bily wrote:
> >Debian is parse through /etc/X11/window-managers and execute the first
> window manager that it finds (and is >installed). In a larger
> environment where you have users that prefer one window manager over
> another, a
> >convenient method we u
It's unfortunate that the printer config stuff (and other stuff from
Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the
user has X (or even a VGA card - it might be a serial console).
A shell/dialog solution would be much better.
Thanks
Bruce
On Sun, 1 Sep 1996, Glenn Bily wrote:
> 5) If a startup shell script for window managers should also be easy to
> add.
>
> I think that the user should have the possibility of specifying the
> window manager at the startx prompt such as:
>
> startx fvwm
> startx openwin
> startx
>> In addition, the admin's life would only be made easier.
> "Let's see where is perl stuffof course: /usr/perl"
Of course it looks easier if you only ask one question.
"Where are the operating system binaries that should go in users'
paths?"
"Where are the standard C++ libraries? Where i
Larry,
> >Glenn Bily writes:
> >-> > Glenn Bily writes:
> >-> > -> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
> >-> > -> what is left into subdirectories.
> >->
> >-> > This has a number of problems, namely:
> >-> > 1) Would require changes to binutils for linux that don'
Glenn Bily writes:
-> > Glenn Bily writes:
-> > -> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
-> > -> what is left into subdirectories.
->
-> > This has a number of problems, namely:
-> > 1) Would require changes to binutils for linux that don't have to
-> >happen on
On Sun, 1 Sep 1996, Glenn Bily wrote:
> Bruce,
>
> > >> If /usr/local is really for local configuration then it >shouldn't be in
> > >> /usr.
> >
> > >Yes. It should probably be a symlink to somewhere else out >of the box
> > >on a freshly-installed Debian system. The installation >scripts can do
> Mark,
> This doesn't answer the overall question...why is it there?
>
> --Glenn
> >> > On a debian system I am looking at has a >/usr/local/lib/emacs which I
> >> > consider to be stranded.
> >> Please check that the _cur
> > On a debian system I am looking at has a /usr/local/lib/emacs which I
> > consider to be stranded.
> Please check that the _current_ Emacs package still does this.
Current emacs does *create* the directory (ie. it is in the package
contents), as recommended by the debian packaging guidelines,
Bruce,
> >> If /usr/local is really for local configuration then it >shouldn't be in
> >> /usr.
>
> >Yes. It should probably be a symlink to somewhere else out >of the box
> >on a freshly-installed Debian system. The installation >scripts can do
> >that. Please submit a bug report on the "boot-flo
[EMAIL PROTECTED] (Bruce Perens) writes:
> (like RCS) on /etc . "dpkg" doesn't currently know how to check control files
> in and out of RCS - is this a good idea? Currently, it will leave a
> "filename.dpkg-new" file around for you to hand-edit if you decline to
> over-write a control file.
This
From: Glenn Bily <[EMAIL PROTECTED]>
> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
> what is left into subdirectories.
>
> A reasonable setup would be:
>
> /usr/lib/elf -- elf shared libs
> /usr/lib/aout -- a.out shared libs
How about /usr/lib/i386-elf and /usr/lib/i386-
> Glenn Bily writes:
> -> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
> -> what is left into subdirectories.
> This has a number of problems, namely:
> 1) Would require changes to binutils for linux that don't have to
>happen on other systems. Too much work for too lit
> >> Folks,
> >>
> >>
> >> These ideas are being posted here from net news per >request.
> >> Response is desired (even if it's not Debian priority)
> > [...]
> >> 3) Server and client installation distinctions. Possible >avenue for easy
> >> minimal setup of X clients.
> >>
> >> A person insta
Glenn Bily writes:
-> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
-> what is left into subdirectories.
This has a number of problems, namely:
1) Would require changes to binutils for linux that don't have to
happen on other systems. Too much work for too little gain.
2
Folks,
These ideas are being posted here from net news per request.
Response is desired (even if it's not Debian priority)
1) Long awaited cleaning out of /usr/lib. In addition, categorizing
what is left into subdirectories.
A reasonable setup would be:
/usr/lib/elf -- elf shared libs
/usr/li
24 matches
Mail list logo
