Re: Mac OSX TeX / To X11 or Not?

Re: Mac OSX TeX / To X11 or Not?

[Ajanta]

David Kastrup <David.Kastrup@t-online.de> wrote:

> If you produce scientific articles, you _need_ either
> <URL:http://www.gnu.org/software/emacs/emacs.html> or
> <URL:http://www.xemacs.org>, and all of

I assume you have successfully built both of these on OS X. I have
10.2.2, with Developer Tools installed. However my attempts to build
either one failed.

GNU Emacs: 21.2 (which appears to be the most recent public release)
refused even ./configure. I followed Andrew Choi's instructions and got
a later (21.3 beta?) version by CVS; this one ran ./configure but make
eventually failed.

XEmacs: I got 21.4; both configure and make ran fine but gave me a
terminal-like emacs. Apparently couldn't detect any windowing system on
the mac!

Is there any special trick to compiling either of these versions on OSX?

Ajanta

Re: Mac OSX TeX / To X11 or Not?

[Raffael Herzog]

Hi Ajanta,

Ajanta wrote:

> I assume you have successfully built both of these on OS X. I have
> 10.2.2, with Developer Tools installed. However my attempts to build
> either one failed.

I don't know MacOS X at all, but a friend of mine found a
package for GNU Emacs 21. It was just a few clicks to ins-
tall Emacs on MacOS X. AFAIK, XEmacs doesn't support Aqua.


cu,

   Raffi


-- 
=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html <=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - herzog@raffael.ch - http://www.raffael.ch - ICQ #67961355

Re: Mac OSX TeX / To X11 or Not?

[Rodney Sparapani]

For binary versions of GNU Emacs for OS X, check out
http://www.esm.psu.edu/mac-tex/ under editors.

-- 
Rodney Sparapani              Medical College of Wisconsin
Sr. Biostatistician           Patient Care & Outcomes Research
rsparapa@mcw.edu              http://www.mcw.edu/pcor
Was 'Name That Tune' rigged?  WWLD -- What Would Lombardi Do

Re: Mac OSX TeX / To X11 or Not?

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> GNU Emacs: 21.2 (which appears to be the most recent public release)
> refused even ./configure. I followed Andrew Choi's instructions and got
> a later (21.3 beta?) version by CVS; this one ran ./configure but make
> eventually failed.

Maybe that bug can be fixed?

> XEmacs: I got 21.4; both configure and make ran fine but gave me a
> terminal-like emacs. Apparently couldn't detect any windowing system on
> the mac!

I think that XEmacs can use X11 on the Mac.  You can get X11 on the
Mac with XDarwin, I think.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Mac OSX TeX / To X11 or Not?

[Schone Mullerin]

In article <061220020416350201%ajanta@no.spam>, Ajanta wrote:
> I followed Andrew Choi's instructions and got
> a later (21.3 beta?) version by CVS; this one ran ./configure but make
> eventually failed.

This is a cvs tree, so it's frequently broken for "minority"
platforms.  The current sources as of yesterday, for example, were
broken for darwin/osx (emacs/lib-src/getopt.c).  When this happens you
generally need to checkout an earlier version of the problematic file.



> XEmacs: I got 21.4; both configure and make ran fine but gave me a
> terminal-like emacs. Apparently couldn't detect any windowing system on
> the mac!

Do you have a full X11 installed (headers etc)?

For xemacs as well as an X11 build of gnu emacs you should consider
using fink's configuration instead of doing it manually.  Likewise
texinfo.

Re: Mac OSX TeX / To X11 or Not?

[Andrew Choi]

Schone Mullerin <smullerin@deutsches.lieder.net> writes:

> In article <061220020416350201%ajanta@no.spam>, Ajanta wrote:
> > I followed Andrew Choi's instructions and got a later (21.3 beta?)
> > version by CVS; this one ran ./configure but make eventually failed.
> 
> This is a cvs tree, so it's frequently broken for "minority"
> platforms.  The current sources as of yesterday, for example, were
> broken for darwin/osx (emacs/lib-src/getopt.c).  When this happens you
> generally need to checkout an earlier version of the problematic file.

Oh no, not again.  This patch will fix it:

Index: getopt.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/getopt.c,v
retrieving revision 1.21
diff -u -r1.21 getopt.c
--- getopt.c    5 Dec 2002 15:30:09 -0000       1.21
+++ getopt.c    6 Dec 2002 17:32:51 -0000
@@ -83,7 +83,11 @@
 # include "gettext.h"
 #endif
 #endif
+#ifdef HAVE_LIBINTL_H
 #define _(msgid) gettext (msgid)
+#else
+#define _(msgid) (msgid)
+#endif
 
 #if defined _LIBC && defined USE_IN_LIBIO
 # include <wchar.h>

Emacs 21.3.50 on Mac OSX 10.2.2

[Ajanta]

[Deleted the xemacs group, but keeping comp.text.tex since this whole
exercise is TeX-related for me]

Andrew Choi <akochoi_NOSPAM_@shaw.ca> wrote:

> Oh no, not again.  This patch will fix it:
> 
> Index: getopt.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lib-src/getopt.c,v
> retrieving revision 1.21
> ... 

Thanks. I am sure this would have helped. Fortunately I was able to get
the emacs 21.3.50 built by Enrico Franconi, also thanks to Rodney
Sparapani earlier in the thread. (For future reference, what does a
"patch" like this mean? For example would the file getopt.c get
*replaced* by this text, *appended* or something else? Sorry, very
little compiling experience here...)

Franconi's compilation, "which does work out of the box" and is an
extremely recent build (Dec 2) available at
http://www.cs.man.ac.uk/%7Efranconi/mac-emacs ,

still leaves me with a few questions:

1. There seem to be *three* executables of identical size (my disk is
not full, but why waste 16MB if one doesn't have to?):

/Applications/Emacs.app/Contents/MacOS/Emacs*
/Applications/Emacs.app/Contents/Resources/bin/emacs*
/Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*

The first of these is probably what does the work because I can run
it from the terminal by typing its path name. The other two seem
to be using up 16MB for no good reason I can decipher: they don't even
run [I get Fatal error (6).Abort]. What are they for and can I safely
delete them? Even if they are needed, shouldn't a symbolic link
suffice?

2. Speaking of disk space, I am not going to use any language besides
English. How can I safely delete the code supporting other langauges
and save some disk space? In doing this manually, I am afraid of
inadvertantly deleting some file that supports latin/ascii or symbols.
(There ought to be a script to do this, probably a make target.)

Basically, emacs is a large distribution and I want to clean up
everythign I don't actually need. This includes duplicate executables,
non-English support, and sources needed to build emacs but not to run
it lnow.

3. When running emacs, "preference" panel in toolbar is broken.

4. The window is normal video (black text on white background).
I would prefer reverse video (white text on black background) if
possible. How to get that?

5. At some point (I must have pressed the wrong key) the program
complained I don't have ispell. That is true, I haven't gotten around
to it and should. However, would aspell be better, as some claim, and
if so how to make emacs work with it instead?

Thanks to every one. This is great help.

A

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Stefan Monnier <foo@acm.com>]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:
> 1. There seem to be *three* executables of identical size (my disk is
> not full, but why waste 16MB if one doesn't have to?):
> /Applications/Emacs.app/Contents/MacOS/Emacs*
> /Applications/Emacs.app/Contents/Resources/bin/emacs*
> /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*

Check their inodes: they should be hardlinks and thus wasting even less
space than symlinks.

> 2. Speaking of disk space, I am not going to use any language besides

What kind of machine are you running this on ?
I ask because my machine is about 6 years old by now and yet 50MB of
disk space is not a big concern.  This is not just rhetorical: the
version 21.3.50 you're using is significantly larger than 21.2 and
this was the result of a conscious decision, so I'd be interested to hear
of how serious a problem it might be.

> 3. When running emacs, "preference" panel in toolbar is broken.

It is generally safe to assume that "broken" is a hopelessly useless
characterization of a behavior.  Please expand.

> 4. The window is normal video (black text on white background).
> I would prefer reverse video (white text on black background) if
> possible. How to get that?

Maybe the -rv option ?  Otherwise, M-x customize-face RET default RET
and change the foreground/background colors.

> 5. At some point (I must have pressed the wrong key) the program
> complained I don't have ispell. That is true, I haven't gotten around
> to it and should. However, would aspell be better, as some claim, and
> if so how to make emacs work with it instead?

aspell emulates ispell so the ispell support works with aspell as well.
Maybe someone has improved Emacs' ispell support to take advantage of
some of the new features offered by aspell but I haven't heard about it.


        Stefan

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Ajanta]

Stefan Monnier <foo@acm.com> wrote:

> >>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:
> > 1. There seem to be *three* executables of identical size (my disk is
> > not full, but why waste 16MB if one doesn't have to?):
> > /Applications/Emacs.app/Contents/MacOS/Emacs*
> > /Applications/Emacs.app/Contents/Resources/bin/emacs*
> > /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*
> 
> Check their inodes: they should be hardlinks and thus wasting even less
> space than symlinks.

I am not familar with inodes. However, I do remember that the dir size
decreases by 16MB when I moved the files out. I played around like that
and the disk space seemed real. Anyway, why do we need three
executables two of which seem to do nothing?

> What kind of machine are you running this on ?

Powerbook, 10.2.2, a few weeks old.

> I ask because my machine is about 6 years old by now and yet 50MB of
> disk space is not a big concern.  This is not just rhetorical: the
> version 21.3.50 you're using is significantly larger than 21.2 and
> this was the result of a conscious decision, so I'd be interested to hear
> of how serious a problem it might be.

I don't have a space crunch yet. I just want to get in to the habit of
not accumulating things that aren't needed. In the release 21.3.50,
Emacs.app is approx 120MB.

> > 3. When running emacs, "preference" panel in toolbar is broken.
> 
> It is generally safe to assume that "broken" is a hopelessly useless
> characterization of a behavior.  Please expand.

It is "unhighlighted" in the mac style. You can't open the panel.

> > 4. The window is normal video (black text on white background).
> > I would prefer reverse video (white text on black background) ... 
> Maybe the -rv option ?  Otherwise, M-x customize-face RET default RET
> and change the foreground/background colors.

Don't know how to give the -rv option when I am clicking on an icon in
the dock, which is how I'd mostly run this program. In most mac-style
apps I would expect to set such things in a Preferences panel. Anyway,
I'll try the customize-face way that you  suggested.

A

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> I am not familar with inodes. However, I do remember that the dir size
> decreases by 16MB when I moved the files out. I played around like that
> and the disk space seemed real. Anyway, why do we need three
> executables two of which seem to do nothing?

Please use `ls -i' to show the inode numbers.  If they are the same
then don't worry about the space.

`du' might produce wrong results when hardlinks are present.

You might wish to look at the output of `df' after removing the
file.  That will tell you the free space on the disk, and it isn't
fooled by hardlinks.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Ajanta]

 Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:

> Please use `ls -i' to show the inode numbers.  If they are the same
> then don't worry about the space.

Thanks. I get the following for inodes with 'ls -i':

339997  /Applications/Emacs.app/Contents/MacOS/Emacs*
340006  /Applications/Emacs.app/Contents/Resources/bin/emacs*
340007  /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*

They are identical size (7912316).

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

>  Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:
>
>> Please use `ls -i' to show the inode numbers.  If they are the same
>> then don't worry about the space.
>
> Thanks. I get the following for inodes with 'ls -i':
>
> 339997  /Applications/Emacs.app/Contents/MacOS/Emacs*
> 340006  /Applications/Emacs.app/Contents/Resources/bin/emacs*
> 340007  /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*
>
> They are identical size (7912316).

Ah, so they are not hard links.  Hm.  Bad.  Try to use cmp on them to
verify that they are really the same.  If they are, you can remove
all but one of them and create hard links manually.  For example:

cd /Applications/Emacs.app/Contents/Resources/bin/
rm emacs-21.3.50
ln emacs emacs-21.3.50
rm ../../../MacOS/Emacs
ln emacs ../../../MacOS/Emacs
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Stefan Monnier <foo@acm.com>]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:
> 339997  /Applications/Emacs.app/Contents/MacOS/Emacs*
> 340006  /Applications/Emacs.app/Contents/Resources/bin/emacs*
> 340007  /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*

Bad!
Please send a bug-report (after checking with whoever made the Emacs.app
package that he followed the normal instructions).
M-x report-emacs-bug is the way to send a bug-report, BTW.


        Stefan

For Andrew Choi/Enrico Franconi: Bug in Emacs 21.3.50

[Ajanta]

Sorry, my email is messed up today. Hope this message will get to you. 

1. I believe the following to be a bug. The Mac OSX version of 21.3.50
contains three executables inside Emacs.app, with different inode
numbers (thanks to Stefan Monnier):

  339997  /Applications/Emacs.app/Contents/MacOS/Emacs*
  340006  /Applications/Emacs.app/Contents/Resources/bin/emacs*
  340007  /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*

They are identical size (7912316). Seems like a waste of HD space.

2. This is of course not a bug but would be a great feature if
implemented: a simple way to delete support for all unwanted languages
(don't know howm much space those things take). I for example only need
English. The best would be some sort of script that people could
configure (i.e., which languages you want to keep), and then run it to
delete the rest.

Thanks.

A

Re: For Andrew Choi/Enrico Franconi: Bug in Emacs 21.3.50

[Andrew Choi]

Ajanta <ajanta@no.spam> writes:

> 1. I believe the following to be a bug. The Mac OSX version of 21.3.50
> contains three executables inside Emacs.app, with different inode
> numbers (thanks to Stefan Monnier):
> 
>   339997  /Applications/Emacs.app/Contents/MacOS/Emacs*
>   340006  /Applications/Emacs.app/Contents/Resources/bin/emacs*
>   340007  /Applications/Emacs.app/Contents/Resources/bin/emacs-21.3.50*
> 
> They are identical size (7912316). Seems like a waste of HD space.
 
If you're using mac/make-package, try using the --app-symlink option.
If you're using `make' try changing the line

  cd ${emacsapp}Contents/MacOS/; cp ../../../../src/emacs Emacs

in src/Makefile.in to

  cd ${emacsapp}Contents/MacOS/; ln ../../../../src/emacs Emacs

Also simply delete whichever executable you don't want.

> 2. This is of course not a bug but would be a great feature if
> implemented: a simple way to delete support for all unwanted languages
> (don't know howm much space those things take). I for example only need
> English. The best would be some sort of script that people could
> configure (i.e., which languages you want to keep), and then run it to
> delete the rest.

This is not Mac specific.  Other people are better qualified to answer
it.  It has most likely been discussed many times before so please
search the archives for answers.

Re: For Andrew Choi/Enrico Franconi: Bug in Emacs 21.3.50

[Stefan Monnier <foo@acm.com>]

> 2. This is of course not a bug but would be a great feature if
> implemented: a simple way to delete support for all unwanted languages
> (don't know howm much space those things take). I for example only need

The size of emacs/lisp/language is about 700KB here.  Peanuts.

The amount of space used up by the other emacs/lisp/international features
(mostly support for various charsets) is less than 4MB.  Not worth
the trouble.

The amount of disk space used by the various input methods (that allow
you to enter accented chars, chinese chars, ...) is about 20MB.  This
used to be distributed separately in the `leim' library.
You can delete the `leim' subdirectory to recover those 20MB and I don't
think you'll suffer any consequence.

> English. The best would be some sort of script that people could
> configure (i.e., which languages you want to keep), and then run it to
> delete the rest.

HD space is not expensive enough to justify wasting any time on this.


        Stefan

Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Ajanta]

Stefan Monnier <foo@acm.com> wrote:

> The size of emacs/lisp/language is about 700KB here.  Peanuts. 
>...
> The amount of space used up by the other emacs/lisp/international features
> (mostly support for various charsets) is less than 4MB.  Not worth
> the trouble.
> ...
> HD space is not expensive enough to justify wasting any time on this.
 
First of all, thank you for all the help. Secondly, I do have a
slightly different philosophical perspective on unneeded disk clutter,
perhaps rooted in my familarity with the third world. 

You see, people in the 3rd world produce much less trash than say the
US. And their urban poor actually "recycle" most of it. Yet, without
systematic and uncompromising management, it still keeps adding up, and
their cities are living hell compared to American cities that in fact
generate a lot more garbage. 

The difference is in constant sorting and processing, of even the
smallest piece of paper or plastic, shall we say of even a single
peanut shell? :) 

In fact many 3rd world people show remarkably similar attitude: the
Forest/River/Beach is so big and I am just throwing one candy wrapper,
what's the big deal?

To make a long story short I believe all programs should come with
tools to minimize unnecessary clutter and also to safely and completely
uninstall themselves if asked.

A

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Galen Boyer]

On Tue, 10 Dec 2002, ajanta@no.spam wrote:
> Stefan Monnier <foo@acm.com> wrote:
> 
>> The size of emacs/lisp/language is about 700KB here.  Peanuts.
>>...
>> The amount of space used up by the other
>> emacs/lisp/international features (mostly support for various
>> charsets) is less than 4MB.  Not worth the trouble.  ...  HD
>> space is not expensive enough to justify wasting any time on
>> this.
>  
> First of all, thank you for all the help. Secondly, I do have a
> slightly different philosophical perspective on unneeded disk
> clutter, perhaps rooted in my familarity with the third world.
> 
> You see, people in the 3rd world produce much less trash than
> say the US. And their urban poor actually "recycle" most of
> it. Yet, without systematic and uncompromising management, it
> still keeps adding up, and their cities are living hell
> compared to American cities that in fact generate a lot more
> garbage.
> 
> The difference is in constant sorting and processing, of even
> the smallest piece of paper or plastic, shall we say of even a
> single peanut shell? :)
> 
> In fact many 3rd world people show remarkably similar attitude:
> the Forest/River/Beach is so big and I am just throwing one
> candy wrapper, what's the big deal?
> 
> To make a long story short I believe all programs should come
> with tools to minimize unnecessary clutter and also to safely
> and completely uninstall themselves if asked.

Whew!

Can you send an encrypted phone number to your dealer?  My stash
of really awesome POT is getting low.

-- 
Galen Boyer

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Phillip Lord]

>>>>> "Galen" == Galen Boyer <galenboyer@hotpop.com> writes:

  Galen> On Tue, 10 Dec 2002, ajanta@no.spam wrote:

  >> First of all, thank you for all the help. Secondly, I do have a
  >> slightly different philosophical perspective on unneeded disk
  >> clutter, perhaps rooted in my familarity with the third world.

  Galen> Can you send an encrypted phone number to your dealer?  My
  Galen> stash of really awesome POT is getting low.


Actually, it's not so daft as you might think. 

I went to a conference a while back, where someone was talking about
the problems of computing in the third world. For instance, they
talked about having internet access via satellite. This sounds great,
till you realise that this means you get half an hours access a day,
when the satellite happens to be over head. 

Okay, I hear you cry, why not just use copper wires? Probably cheaper
than satellite access. Well, the problem was that every time they put
up copper wires, someone with a big pair of croppers came along and
took the wire away. Copper is expensive after all. I thought I had
some ideas of the problems the third world might have, but it turns
out that most of my ideas were wrong.

At the end of the day, Stefan's point, that hard drive space is not
worth the effort saving it would entail, is true. Hard drive space is
cheap, while people are expensive. But, of course, this is only true
in some parts of the world. In many parts of the third world, its the
other way around. 

Of course, emacs is not a large offender in this day and age, and
there are many worse. I current have six versions of emacs on my hard
drive, because I've not got around to deleting pretest versions. 

The solution here, though, is the "scratching an itch" one. I can
understand why the emacs maintainers don't want to spend time on
it. Other might though, and they should probably be the ones to submit
patches!

Incidentally, on the pot front, you did know about M-x dealer I
presume?

Phil

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Galen Boyer]

On 10 Dec 2002, p.lord@russet.org.uk wrote:

[Snip of a reasonable explanation, not laden with PCP...]

I still don't understand how, if someone can buy a computer, a
little more disk space is going to kill them.


> Incidentally, on the pot front, you did know about M-x dealer I
> presume?

I didn't get any matches.  Damn.

-- 
Galen Boyer

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Phillip Lord]

>>>>> "Galen" == Galen Boyer <galenboyer@hotpop.com> writes:

  Galen> On 10 Dec 2002, p.lord@russet.org.uk wrote:

  Galen> [Snip of a reasonable explanation, not laden with PCP...]

  Galen> I still don't understand how, if someone can buy a computer,
  Galen> a little more disk space is going to kill them.

You are assuming that they have bought the computer. Perhaps they go
it on a freebie. The first world gets through a lot of computers, and
many of the old ones head out to the third world. I know its hard to
believe, but there are many many people out there still using 486's. 




  >> Incidentally, on the pot front, you did know about M-x dealer I
  >> presume?

  Galen> I didn't get any matches.  Damn.


M-x spark.

Also worth while is M-x bogart, if you start to cop a whitey. 

Phil

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Ajanta]

Phillip Lord <p.lord@russet.org.uk> wrote:

> At the end of the day, Stefan's point, that hard drive space is not
> worth the effort saving it would entail, is true.  

I didn't get my point across. The problem is not of space but clutter.
If you see some trash thrown around somewhere, it is not necessarily
occupying a large % of the space or volume. But it is still clutter,
that would add up. However, I would concede that tolerance for or
aversion to such things is probably a matter of personal taste. 

> Hard drive space is cheap, while people are expensive.

Of course it would be some effort to clean up an old warehouse, but
keeping a house clean, if done regularly with good habits in the first
place, is not such a big deal. So is the case with software.

> I current have six versions of emacs on my hard drive, because I've not 
> got around to deleting pretest versions. 

Your life, your choice. I just picked up a toast that had fallen on the
floor. My lunch, my choice. :) But to guest or even in a soup kitchen,
I wouldn't do that. Standards are different when you are serving
others, with or without charge.
 
> I can understand why the emacs maintainers don't want to spend time on
> it. Other might though, and they should probably be the ones to submit
> patches!

I think it is a matter of overall awareness, and also some discipline
being imposed by the people who are in-charge.

A

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Phillip Lord]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:

  Ajanta> Phillip Lord <p.lord@russet.org.uk> wrote:

  >> At the end of the day, Stefan's point, that hard drive space is
  >> not worth the effort saving it would entail, is true.

  Ajanta> I didn't get my point across. The problem is not of space
  Ajanta> but clutter.  If you see some trash thrown around somewhere,
  Ajanta> it is not necessarily occupying a large % of the space or
  Ajanta> volume. But it is still clutter, that would add up. However,
  Ajanta> I would concede that tolerance for or aversion to such
  Ajanta> things is probably a matter of personal taste.

Well this is a different issue. Clutter for me is a problem in user
space. I keep my home space relatively clean, because otherwise its
hard to use. I am rigorous about avoiding duplication of all sorts,
because otherwise I make mistakes. 

In space managed my the machine (like for instance a make file
installed emacs), I couldn't care less about duplication, or
clutter. Computers don't get confused by clutter. 

Phil

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Phillip Lord]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:

  Ajanta> Phillip Lord <p.lord@russet.org.uk> wrote:

  >> Well this is a different issue. Clutter for me is a problem in
  >> user space... In space managed my the machine (like for instance
  >> a make file installed emacs), I couldn't care less about
  >> duplication, or clutter. Computers don't get confused by clutter.

  Ajanta> However, since computers are there for users, there is bound
  Ajanta> to be some overlap. One might want to know just what
  Ajanta> commands are there in one's various bin's, what they do, who
  Ajanta> put them there and why. In tricky situations the only way to
  Ajanta> understand a program better may be to actuallly browse its
  Ajanta> directories and files, so clutter there would hurt.


Of course this is true. But there are some parts of my computer that I
look at, and some that I don't. The internals of an installed emacs, I
don't. Its much more important that the Makefile, or the autoconf
script, or what ever, is uncluttered than the final file system is. If
you have to put in a lot of stuff, removing the excess files, then you
are trading one for the other.

You win somethings, you loose others. 

Phil

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Ajanta]

 Phillip Lord <p.lord@russet.org.uk> wrote:
>  Its much more important that the Makefile, or the autoconf
> script, or what ever, is uncluttered than the final file system is. If
> you have to put in a lot of stuff, removing the excess files, then you
> are trading one for the other.

Actually I don't understand this equivalence. Makefiles routinely come
with targets like "clean" which presumably deletes files like .log/.o
and of course "install".  If they could have a few extra targets, like
"superclean" or "EnglishOnly", that's a few extra lines. Why is that
comparable with the clutter of tens of MB and 100's of files scattered
around? If you can have "make install", why not "make uninstall" which
would merely remove all the installed files and links?

A

Re: Software/HD ecology

[Henrik Enberg]

Ajanta <ajanta@no.spam> writes:
 
> Makefiles routinely come with targets like "clean" which presumably
> deletes files like .log/.o and of course "install".  If they could
> have a few extra targets, like "superclean" or "EnglishOnly", that's a
> few extra lines. 

There are dependencies in the source code and the manuals.  Simply
removing the files is not a very pretty thing to do.

> Why is that comparable with the clutter of tens of MB and 100's of
> files scattered around? If you can have "make install", why not "make
> uninstall" which would merely remove all the installed files and
> links?

The Emacs Makefiles are created by a configure script.  If any part of
the config changes, It isn't the same Makefile.  You might remove the
wrong files then, unless you keep the unpacked and compiled tarball
around.

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Stefan Monnier <foo@acm.com>]

> "EnglishOnly"

And "FrenchOnly" and "GermanOnly" and "EnglishAndFrenchOnly" and
"ChineseAndEnglishOnly" and ... ?
Or are you going to claim that we should not care about non-English users ?

> Why is that comparable with the clutter of tens of MB and 100's of files
> scattered around?

Could you expand on your "scattered around" ?
As maintainers, it's in our own interest to keep things uncluttered,
so we strive to find some logic to things such that we can organize our
files and keep files in their logical place.  So please explain which files
or functions you think are "scattered around" and where they should
be instead ?
I don't claim that the current arrangement is perfect, but it takes time
and energy to think about how to make it better and to fix the various
places where things aren't consistent and logical, so help is most welcome.


        Stefan

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Ajanta]

 Stefan Monnier <foo@acm.com> wrote:

> > "EnglishOnly" 
> And "FrenchOnly" and "GermanOnly" and "EnglishAndFrenchOnly" and
> "ChineseAndEnglishOnly" and ... ?
> Or are you going to claim that we should not care about non-English users ?

Well, there are *hundreds* of langauges in the world: which one would
you not want to "care" about? Sooner or later "internationalization"
has got to mean not just *adding* things but also *selecting* them.
Maybe this should be done at configure stage, via options, or
interactively, oe some other way. It is for the programmers to figure
out the best way, but the time to start thinking about it is now.

> > Why is that comparable with the clutter of tens of MB and 100's of files
> > scattered around?
> 
> Could you expand on your "scattered around" ?

I didn't keep a tally but here is an example. I recently I obtained a
beta distribution (not emacs) which didn't work out (fair enough,
that's a known risk in beta) and I deleted it. Or so I thought. I still
keep running into some files from it. What gives me pause is that these
are the ones I recognize because of the way they are named. There are
many whose names mean nothing to me, I don't know which program they
belong to, so they'll lie around. (At first, I did take a shot in the
dark and tried "make uninstall", but it didn't work.)

As I mentioned in the beginning post of this thread, the distribution
of Emacs 21.3.50 that I got for Mac OSX has *three* executables of
identical size but different inodes. This makes no sense at all.

A

Re: Software/HD ecology

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> I didn't keep a tally but here is an example. I recently I obtained a
> beta distribution (not emacs) which didn't work out (fair enough,
> that's a known risk in beta) and I deleted it. Or so I thought.

I run Linux instead of MacOS, but maybe this approach works there,
too?

At our site, we have a directory for software with subdirs for each
program, and subsubdirs for each version.  For example, 

    ./configure --prefix=/usr/sw/emacs/21.2

is sufficient to configure Emacs in such a way that subsequent `make'
and `make install' can be undone easily by just removing the
directory /usr/sw/emacs/21.2.  This works because Emacs is the only
program in that directory.

It's a very simple approach, but it works well enough for us.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Bijan Soleymani]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> At our site, we have a directory for software with subdirs for each
> program, and subsubdirs for each version.  For example, 
> 
>     ./configure --prefix=/usr/sw/emacs/21.2
> 
> is sufficient to configure Emacs in such a way that subsequent `make'
> and `make install' can be undone easily by just removing the
> directory /usr/sw/emacs/21.2.  This works because Emacs is the only
> program in that directory.
> 
> It's a very simple approach, but it works well enough for us.
> 
> -- 

In that case you might want to check out GNU stow. You put all your
software in a stow directory /usr/local/stow/ or /usr/sw/ one program
per subdirectory. Then when you run stow it makes symlinks in
/usr/local/. This way you can even do this sort of thing with
libraries or  programs you would like to have in your path.

Bijan

Re: Software/HD ecology

[Kai Großjohann]

Bijan Soleymani <bijan@psq.com> writes:

> In that case you might want to check out GNU stow. You put all your
> software in a stow directory /usr/local/stow/ or /usr/sw/ one program
> per subdirectory. Then when you run stow it makes symlinks in
> /usr/local/. This way you can even do this sort of thing with
> libraries or  programs you would like to have in your path.

I don't use Stow, but I think it's not a (complete) solution.  We have
several versions of Java installed in /usr/sw/java, and some people
need one version whereas other people need another version (on the
same machine).

I'm thinking about making a directory /usr/sw/bin and populating it
with symlinks, but currently, we don't have enough software packages
to justify this effort.  (Happily, Debian provides lots of packages
so we don't have to install too many of them.)
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Anil Trivedi]

Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:

> I'm thinking about making a directory /usr/sw/bin and populating it
> with symlinks, but currently, we don't have enough software packages
> to justify this effort.  (Happily, Debian provides lots of packages
> so we don't have to install too many of them.)

This is not the most deeply probing question, but is /usr/sw simply
your personal preference or is there a good reason for avoiding the
more traditional name /usr/local ? (I am curious because I just started
installing a few programs and have been putting them in /usr/local).

Re: Software/HD ecology

[Kai Großjohann]

Anil Trivedi <anil@null.invalid> writes:

> This is not the most deeply probing question, but is /usr/sw simply
> your personal preference or is there a good reason for avoiding the
> more traditional name /usr/local ?

Well, maybe it's just a combination of little things, but nothing
compelling.  The little things do not apply generally, just to us.

We started in an environment where /usr/local was a directory which
was managed by somebody else (the departmental computing center, on
our SunOS 4.x workstations).  We used /usr/local/ls6 at that time,
but felt the directory name was too long.  Later on, the departmental
computing center changed to /app/unido-inf/sun4_56 (Solaris 2.6, no
surprise), and so we used /app/unido-i06/sun4_56 which wasn't really
any shorter either.

Then, when we moved to GNU/Linux, we instinctively stayed away from
all these directories I think and looked for something else.  I had
seen /usr/sww (software warehouse) in some document on the internet
and I liked that, so maybe that's why /usr/sw came about.

One additional reason to stay away from /usr/local is that I used
FreeBSD on my home system for a while, and there the /usr/local
directory is managed by the Ports system.

Why didn't we use /sw instead?  The reason is really silly: back on
SunOS and Solaris, we used to mount /usr via NFS, so putting mount
points under /usr was easier because we only had to create the
directory on the NFS server.  But now with GNU/Linux, we don't
distribute /usr via NFS...

So I think the upshot is that there is no good reason, just personal
preferences.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Kai" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:

    Kai> We started in an environment where /usr/local was a directory
    Kai> which was managed by somebody else (the departmental
    Kai> computing center, on our SunOS 4.x workstations).  We used
    Kai> /usr/local/ls6 at that time, but felt the directory name was
    Kai> too long.  Later on, the departmental computing center
    Kai> changed to /app/unido-inf/sun4_56 (Solaris 2.6, no surprise),
    Kai> and so we used /app/unido-i06/sun4_56 which wasn't really any
    Kai> shorter either.

If you're on the command line:

        $ x=/app/unido-i06/sun4_56

and after that, you can:

        $ ls $x
        $ find $x -perm +0111
etc.


    Kai> Then, when we moved to GNU/Linux, we instinctively stayed
    Kai> away from all these directories I think and looked for
    Kai> something else.  I had seen /usr/sww (software warehouse) in
    Kai> some document on the internet and I liked that, so maybe
    Kai> that's why /usr/sw came about.

Users should not need to use  these pathnames so much.  Use aliases or
shell scripts.


    Kai> Why didn't we use /sw instead?  The reason is really silly:
    Kai> back on SunOS and Solaris, we used to mount /usr via NFS, so
    Kai> putting mount points under /usr was easier because we only
    Kai> had to create the directory on the NFS server.  But now with
    Kai> GNU/Linux, we don't distribute /usr via NFS...

Why not?  NFS-shared volumes are easier to manage if you have a large
network.  This is esp. true with softwares that you install from
source or tarballs, not package files.



-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Kai Großjohann]

Lee Sau Dan <danlee@informatik.uni-freiburg.de> writes:

> Users should not need to use  these pathnames so much.  Use aliases or
> shell scripts.

Actually, with the previous system I used to do 

    module add i06/edit/emacs/20.7

and after that I could type "emacs" to invoke that version of Emacs.
Quite nifty, actually.

These days we cheat by having /usr/sw/emacs/20.7/.bashenv which people
source to achieve the same effect.  But this doesn't give us the
effect of doing "module rm i06/edit/emacs/20.7"...

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Kai" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:

    Kai> Lee Sau Dan <danlee@informatik.uni-freiburg.de> writes:
    >> Users should not need to use these pathnames so much.  Use
    >> aliases or shell scripts.

    Kai> Actually, with the previous system I used to do

    Kai>     module add i06/edit/emacs/20.7

    Kai> and after that I could type "emacs" to invoke that version of
    Kai> Emacs.  Quite nifty, actually.

The GCC  commandline front lets  you select which compiler  version to
use via the -V option, if you have several versions installed.



-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Kevin Rodgers]

Anil Trivedi wrote:

> This is not the most deeply probing question, but is /usr/sw simply
> your personal preference or is there a good reason for avoiding the
> more traditional name /usr/local ? (I am curious because I just started
> installing a few programs and have been putting them in /usr/local).

Stick with /usr/local.  We just had some confusion at my site over the fact
that Sun has started to distribute some open source/free software in /opt/sfw.
We decided to make /usr/local a symbolic link to /opt/sfw so that default
GNU etc. configurations would get installed in the same place.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Software/HD ecology

[David Masterson]

>>>>> Kevin Rodgers writes:

> Anil Trivedi wrote:
>> This is not the most deeply probing question, but is /usr/sw simply
>> your personal preference or is there a good reason for avoiding the
>> more traditional name /usr/local ? (I am curious because I just started
>> installing a few programs and have been putting them in /usr/local).

> Stick with /usr/local.  We just had some confusion at my site over
> the fact that Sun has started to distribute some open source/free
> software in /opt/sfw.  We decided to make /usr/local a symbolic link
> to /opt/sfw so that default GNU etc. configurations would get
> installed in the same place.

Actually, it may be better to *NOT* use /usr/local, particularly if
you're trying to build a /usr/local for a number of operating
systems.  By leaving /usr/local open to being just a symlink farm,
it's easier to manipulate what to put in there (as in "scripts from
the generic depot and exes from the O/S depot").  Ultimately, you may
want to have multiple /usr/local directories (one for "LatestDevel",
one for "BugTest", one for "Support", etc.).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Kevin Rodgers]

David Masterson wrote:

> Actually, it may be better to *NOT* use /usr/local, particularly if
> you're trying to build a /usr/local for a number of operating
> systems.  By leaving /usr/local open to being just a symlink farm,
> it's easier to manipulate what to put in there (as in "scripts from
> the generic depot and exes from the O/S depot").  Ultimately, you may
> want to have multiple /usr/local directories (one for "LatestDevel",
> one for "BugTest", one for "Support", etc.).


Good point.  But at my site, development, test, and production software

is separated by machine (devl1, ... devlN, stage1, ..., stageN, and
prod1, ..., prodN) and the machines within each category are kept in
sync.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Software/HD ecology

[Anil Trivedi]

Kevin Rodgers <kevin.rodgers@ihs.com> wrote:
> Stick with /usr/local.  We just had some confusion at my site over the fact
> that Sun has started to distribute some open source/free software in /opt/sfw.
> We decided to make /usr/local a symbolic link to /opt/sfw so that default
> GNU etc. configurations would get installed in the same place.

I learned a little more in the last day or so. Fink site says they
avoid /usr/local because it is commonly used and one 3rd party may
overwrite another. So they prefer /sw, as an abbreviation for
"software" this seems risky too, perhaps /finksw would have been better
or a completely neutral name nobody else would chance upon. Anyway,
hoping that such conflicts won't arise in the few programs I am likely
to install, I am sticking with /usr/local, as you advise.

Anil

Re: Software/HD ecology

[David Masterson]

>>>>> Kai Großjohann writes:

> Bijan Soleymani <bijan@psq.com> writes:

>> In that case you might want to check out GNU stow. You put all your
>> software in a stow directory /usr/local/stow/ or /usr/sw/ one
>> program per subdirectory. Then when you run stow it makes symlinks
>> in /usr/local/. This way you can even do this sort of thing with
>> libraries or programs you would like to have in your path.

> I don't use Stow, but I think it's not a (complete) solution.  We
> have several versions of Java installed in /usr/sw/java, and some
> people need one version whereas other people need another version
> (on the same machine).

I haven't looked at Stow in quite awhile, but it should handle this in
theory.  If it does not, I have an alternative Perl package called
pkglink that works quite well.  Actually, you can get pkglink at:

* http://www.cs.unm.edu/~ssg/SSG_SysAdmin/SSG_Pkglink.shtml

But I've made some enhancements to it since this version (I think mine
is more in-line with automake).  Send me an email if you're interested.

> I'm thinking about making a directory /usr/sw/bin and populating it
> with symlinks, but currently, we don't have enough software packages
> to justify this effort.  (Happily, Debian provides lots of packages
> so we don't have to install too many of them.)

Pkglink can do the symlink farm with multiple versions.  It structures
the directory as follows:

* /usr/local
* Repository
** Package 1
*** Version 1
*** Version 2
** Package 2
*** Version 1
*** Version 2

So you can install as many versions of the software that you need by
just setting the configure "prefix" to the appropriate "Version"
directory before doing the "make install".  Then, using pkglink, you
can pick which version of a package gets symlinked into the main area
(/usr/local, but you could have more than one).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Kai Großjohann]

David Masterson <dmaster@synopsys.com> writes:

> So you can install as many versions of the software that you need by
> just setting the configure "prefix" to the appropriate "Version"
> directory before doing the "make install".  Then, using pkglink, you
> can pick which version of a package gets symlinked into the main area
> (/usr/local, but you could have more than one).

So if two people want to use different Java versions then we would
need two `main areas'?

Hm.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[David Masterson]

>>>>> Kai Großjohann writes:

> David Masterson <dmaster@synopsys.com> writes:

>> So you can install as many versions of the software that you need
>> by just setting the configure "prefix" to the appropriate "Version"
>> directory before doing the "make install".  Then, using pkglink,
>> you can pick which version of a package gets symlinked into the
>> main area (/usr/local, but you could have more than one).

> So if two people want to use different Java versions then we would
> need two `main areas'?

Or they modify their PATH to pick up the Java of their choice from the
particular version directory.  Generally, I'd choose this approach if
it's *only* two people you're talking about.  If, on the other hand,
you're talking about two groups of people (say Development and Test),
then you might want to create two 'main areas'.  Pkgindex can then
give you (and your users) an understanding of what's in each area.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Ajanta]

Bijan Soleymani <bijan@psq.com> wrote:

> In that case you might want to check out GNU stow. You put all your
> software in a stow directory /usr/local/stow/ or /usr/sw/ one program
> per subdirectory. Then when you run stow it makes symlinks in
> /usr/local/. This way you can even do this sort of thing with
> libraries or  programs you would like to have in your path.

I wasn't aware of this and will have to look into it. However, unless a
program's creators cooperate, I can't visualize how stow would prevent
a program from installing files all over the place leaving you with no
way to uninstall?

A practical problem is that except perhaps to an insider most names are
unintuitive. If a file is named emacs-foo or foo.el you can guess what
it is but a name like zuplibfoo (this is hypothetical, but most unix
names have similar transparency) doesn't tell you which of the hundreds
of packages it might belong to. So you can't even try to uninstall
everything manually.

A

Re: Software/HD ecology

[Anil]

Since unix routinely keeps a system-wide log on every file, I am
wondering if it would be desirable to extend that a little. 

Let us say a slightly enhanced version of "ls" could tell you not only
that a file is owned by root, wheel, etc., but also "belongs" to the
System or a user or a package like TeX or Emacs-29.9, and maybe even
its type within that package (src, doc, bin...). This requires one or
two more file attributes, but then you could check on an individual
file with "ls" or list all files belonging to a package with "find".

I think unix was conceptualized for small systems and programs, where a
user might know every file, where it came from, what it does. Either
you wrote it yourself or copied it from a friend. Those times are gone.
We have hundreds of thousands of files, know nothing about them, and
routinely install packages that bring thousands of files. The culture
and the tools have not evolved to deal with this reality and perhaps
need to. 

Shouldn't you be able to know just what a particular file named
"dtabttf" doing on your system? Similarly, while I am glad to know a
files's relationship to "wheel", it would also be useful to know it
belongs to emacs or TeX.

Anil Trivedi

Re: Software/HD ecology

[Kai Großjohann]

Anil <anil@null.invalid> writes:

> Let us say a slightly enhanced version of "ls" could tell you not only
> that a file is owned by root, wheel, etc., but also "belongs" to the
> System or a user or a package like TeX or Emacs-29.9, and maybe even
> its type within that package (src, doc, bin...).

Linux distributions have this.  For example, in Debian you can type
"dpkg -S /path/to/file" and it will tell you which Debian package the
file belongs to.  I'm sure rpm offers a similar command, and probably
the FreeBSD, OpenBSD, NetBSD package tools have it, too.  (And the
fink package management system for MacOS probably has it, too.)

That doesn't help generic Unices, though.  Nor does it help with
programs that you install from the source without building a
Debian/RPM/... package.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Francis Burton]

Anil wrote:
> Let us say a slightly enhanced version of "ls" could tell you not only
> that a file is owned by root, wheel, etc., but also "belongs" to the
> System or a user or a package like TeX or Emacs-29.9, and maybe even
> its type within that package (src, doc, bin...). This requires one or
> two more file attributes, but then you could check on an individual
> file with "ls" or list all files belonging to a package with "find".

Rather than add an extension to handle one very specific problem,
might not this issue be better addressed through use of a more
general attribute-based or "semantic" filesystem?

(See e.g. the work of Gifford et al. at
http://www.psrg.lcs.mit.edu/history/publications/Papers/sfsabs.htm )

> I think unix was conceptualized for small systems and programs, where a
> user might know every file, where it came from, what it does. Either
> you wrote it yourself or copied it from a friend. Those times are gone.
> We have hundreds of thousands of files, know nothing about them, and
> routinely install packages that bring thousands of files. The culture
> and the tools have not evolved to deal with this reality and perhaps
> need to.

It's good to see that people are recognizing and drawing attention
to this problem - a very serious one, imho.

Francis

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Anil" == Anil  <anil@null.invalid> writes:

    Anil> Since unix routinely keeps a system-wide log on every file,

Since when does Unices do that?  Can  you tell me the name of this log
file?


    Anil> Let us say a slightly enhanced version of "ls" could tell
    Anil> you not only that a file is owned by root, wheel, etc., but
    Anil> also "belongs" to the System or a user or a package like TeX
    Anil> or Emacs-29.9, and maybe even its type within that package
    Anil> (src, doc, bin...). This requires one or two more file
    Anil> attributes, but then you could check on an individual file
    Anil> with "ls" or list all files belonging to a package with
    Anil> "find".

'man rpm', if you're on a RedHat or SuSE system.


    Anil> I think unix was conceptualized for small systems and
    Anil> programs, where a user might know every file, where it came
    Anil> from, what it does. 

Wrong.  Unix  has been designed  to be a  multi-concurrent-user system
since  3 decades  ago.   Unix  systems used  to  be time-shared  among
hundreds (in some cases thousands) of concurrent users.  Normally, the
end users only  know about a few subtree of  the whole directory tree,
and that's enough for his work.


    Anil> Either you wrote it yourself or copied it from a
    Anil> friend. Those times are gone.  

They've gone long ago.


    Anil> We have hundreds of thousands of files,

Unix passed this point decades ago.


    Anil> know nothing about them, and routinely install packages that
    Anil> bring thousands of files. The culture and the tools have not
    Anil> evolved to deal with this reality and perhaps need to.

That why we hav package management tools, like RPM on RedHat and SuSE.


    Anil> Shouldn't you be able to know just what a particular file
    Anil> named "dtabttf" doing on your system? 

Unix programmers would have used a more descriptive filenames.


    Anil> Similarly, while I am glad to know a files's relationship to
    Anil> "wheel", it would also be useful to know it belongs to emacs
    Anil> or TeX.

rpm -qf /etc/ntpd.conf



-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Ajanta]

Lee Sau Dan <danlee@informatik.uni-freiburg.de> wrote:
 
>     Anil> Since unix routinely keeps a system-wide log on every file,
> 
> Since when does Unices do that?  Can  you tell me the name of this log
> file?

When I run a command like "ls -l file" I can get a lot of information
about a file's type, size, ownership, date created/modified. Whether
that qualifies as a "log" to somebody or not is a rather dull semantic
issue. The system does store and update information on files.

Re: Software/HD ecology

[Stefan Monnier <foo@acm.com>]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:
> When I run a command like "ls -l file" I can get a lot of information
> about a file's type, size, ownership, date created/modified.  Whether
> that qualifies as a "log" to somebody or not is a rather dull semantic
> issue.  The system does store and update information on files.

These kinds of info are more akin to `state'.  One major difference between
`state' and `log' is that a `log' is `append only'.  The info you describe
is always kept uptodate but you can't know what it was before the last
modification, so it's very clearly not a `log'.

Maybe it's dull, but it's not subtle.  If you don't know what word to use,
just use "info" or "thing" so you won't mislead readers.


        Stefan

Re: Software/HD ecology

[Anil]

 Stefan Monnier <foo@acm.com> wrote:

> >>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:
> > When I run a command like "ls -l file" I can get a lot of information
> > about a file's type, size, ownership, date created/modified.  Whether
> > that qualifies as a "log" to somebody or not is a rather dull semantic
> > issue.  The system does store and update information on files.
> 
> These kinds of info are more akin to `state'.  One major difference between
> `state' and `log' is that a `log' is `append only'.  The info you describe
> is always kept uptodate but you can't know what it was before the last
> modification, so it's very clearly not a `log'.

I worry about many things, but this would be rather low on my list.  If
something came with emacs, it remains with emacs. It doesn't become a
MS Office file!  What *are* you talking about?

> Maybe it's dull, but it's not subtle.  If you don't know what word to use,
> just use "info" or "thing" so you won't mislead readers.

I apologize.  I didn't mean to mislead anyone. When I said unix logs
information, a few posts above, I was writing English and hoped people
would read it as English. How exactly were you misled, though? 

Your suggestion is questionable too: "info" could also have technical
meaning to someone. Probably does. I see no alternative to relying on
other people's common sense to read English as English. 

By the way, you had claimed elsewhere that Emacs files are
well-localized in the file systems. You didn't respond to my post that
on my system I find (just for the *name* emacs, not necessarily all
emacs-specific files):

   /usr/bin/emacs
   /usr/info/emacs
   /usr/libexec/emacs
   /usr/local/bin/emacs
   /usr/share/emacs
   /usr/share/info/emacs

The problem is not one program, emacs or something else. The problem is
fifty or hundred programs, each installing itself in a few places, each
doing so just a little differently. Then, without a standard
"uninstall" culture (which, someone did assure us, is becoming common),
we have a recipe for confusion.

Anil

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Anil" == Anil  <anil@null.invalid> writes:

    >> These kinds of info are more akin to `state'.  One major
    >> difference between `state' and `log' is that a `log' is `append
    >> only'.  The info you describe is always kept uptodate but you
    >> can't know what it was before the last modification, so it's
    >> very clearly not a `log'.

    Anil> I worry about many things, but this would be rather low on
    Anil> my list.  If something came with emacs, it remains with
    Anil> emacs. It doesn't become a MS Office file!  What *are* you
    Anil> talking about?

He's talking about what "log"  means in the field of computing.  "log"
means  kind of historical  record.  Since  history cannot  be changed,
this means log files are never modified, only appended.


    Anil> I apologize.  I didn't mean to mislead anyone. When I said
    Anil> unix logs information, a few posts above, I was writing
    Anil> English and hoped people would read it as English. How
    Anil> exactly were you misled, though?

Even in plain  English, a "log book" is a book  where you keep records
of past, historical events.  It is abnormal to erase an entry in a log
book to make room to record new  entries.  You open a new log book for
that.  New entries are always added to the log in the empty space, not
by replacing existing entries.   Erasing old entries would counter the
purpose of a log book.

So, the file info (e.g. size, mod. time, owner) cannot be classifed as
any kind of "log".


    Anil> Your suggestion is questionable too: "info" could also have
    Anil> technical meaning to someone. 

No, unless  you're talking about GNU  info.  The word  "info" is vague
and hence suitable here.


    Anil> Probably does. I see no alternative to relying on other
    Anil> people's common sense to read English as English.

We do read English as English.  I can't see any reason for calling the
_file  attributes_ "log".  Calling  it "info"  is OK,  as "info"  is a
vague term.


    Anil> By the way, you had claimed elsewhere that Emacs files are
    Anil> well-localized in the file systems. You didn't respond to my
    Anil> post that on my system I find (just for the *name* emacs,
    Anil> not necessarily all emacs-specific files):

Like most GNU  softwares, Emacs gives you (or your  sys admin) lots of
flexibilities,  including the  flexibility  of doing  it  in a  weird,
strange,  non-standard  way.  But  that  doesn't  mean  Emacs MUST  be
configured and installed like that.


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> When I run a command like "ls -l file" I can get a lot of information
> about a file's type, size, ownership, date created/modified. Whether
> that qualifies as a "log" to somebody or not is a rather dull semantic
> issue. The system does store and update information on files.

The "ownership" does NOT tell you whether the file belongs to Emacs or
to another program.  (At least, not in general.)

So you need something in addition to the "log" that comes standard
with Unix.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Ajanta]

 Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:
> Ajanta <ajanta@no.spam> writes:
> 
> > When I run a command like "ls -l file" I can get a lot of information
> > about a file's type, size, ownership, date created/modified. Whether
> > that qualifies as a "log" to somebody or not is a rather dull semantic
> > issue. The system does store and update information on files.
> 
> The "ownership" does NOT tell you whether the file belongs to Emacs or
> to another program.  (At least, not in general.)
> So you need something in addition to the "log" that comes standard
> with Unix.

Yes I do understand that this does not come standard with unix. The
discussion was about the desirability for it to be so. There was a
suggestion that an extention of ls would be a logical choice; the
system would of course have to log/record some extra information in
addition to what it already does . However, some people felt this was a
good opportunity to start arguing over the word "log".

A

Re: Software/HD ecology

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> Yes I do understand that this does not come standard with unix. The
> discussion was about the desirability for it to be so. There was a
> suggestion that an extention of ls would be a logical choice; the
> system would of course have to log/record some extra information in
> addition to what it already does . However, some people felt this was a
> good opportunity to start arguing over the word "log".

Yes, indeed.  Alas, the Unix crowd appears to follow the Perl
philosophy `There is more than one way to do it', and hence, different
Unices have different ways.

Some Linux distributions have rpm, others have dpkg and apt-get.
FreeBSD has pkg_add and friends.  Solaris also has something named
pkgfoo, for some value of foo.  MacOS has fink, amongst others.  Since
MacOS is based on FreeBSD (or is it NetBSD or OpenBSD) in some way,
maybe MacOS also uses pkg_add and friends?

Of course, these tools only do something if they are actually used.
Originally, several files and directories were mentioned; it appears
that at least two versions of Emacs were installed -- one in /usr and
one in /usr/local.  Of course, I have no idea which system maintains
the files.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Rodney Sparapani]

I'm removing comp.text.tex from this discussion.  I read that group and 
these posts
don't belong there :o)  One thing missed so far, is that FreeBSD-based 
Darwin
(which under-pins OS X) has it's own version of packaging called 
bundling (which
is different from fink and came from NeXT).  It is quite nice.  If you 
look around
in your emacs installation you'll find a mac sub-directory and under it 
an Emacs.app
sub-directory.  This is a bundle.  You can place all of the files that 
normal go in
/usr/local under Emacs.app and you have a package.  You can move it 
around or
delete it to your hearts content.  There are instructions on doing so in 
the mac
sub-directory.  Oh, and the source code for Darwin is open so it could 
be ported
to other unices (or should that be unixen?).  End of thread :o)

-- 
Rodney Sparapani              Medical College of Wisconsin
Sr. Biostatistician           Patient Care & Outcomes Research
rsparapa@mcw.edu              http://www.mcw.edu/pcor
Was 'Name That Tune' rigged?  WWLD -- What Would Lombardi Do

Re: Software/HD ecology

[Jonathon Isaac Swiderski]

On Tue, 17 Dec 2002, Kai Großjohann wrote:

> Alas, the Unix crowd appears to follow the Perl
> philosophy `There is more than one way to do it', and hence, different
> Unices have different ways.

You've your history backwards--- UNIX predates Perl by better than ten
years.  Much of the duplication of functionality in UNIX comes from the
SysV/Berkeley split.  Pretty much any introductory UNIX text can explain
what this means; try ORA's "Unix in a Nutshell" for one. "Essential System
Administration", also from O'Reilly, has the most comprehensive I've yet
seen anywhere. (both in unix.ora.com somewhere)

> FreeBSD has pkg_add and friends.  Solaris also has something named
> pkgfoo, for some value of foo.

foo=add  (Solaris' package installer is called pkgadd.)

> MacOS has fink, amongst others.  Since MacOS is based on FreeBSD (or is
> it NetBSD or OpenBSD) in some way, maybe MacOS also uses pkg_add and
> friends?

(assuming that by 'MacOS' you mean 'OS X' . . .)
Fink is a system that ports and packages programs for installation to OS X;
Debian tools (dpkg; apt) are used for installation: fink.sf.net: "We
modify Unix software so that it compiles and runs on Mac OS X ("port" it)
and make it available for download as a coherent distribution."
OS X's Unix subsystem is based on FreeBSD: developer.apple.com: "Darwin is
the core of Mac OS X. The Darwin kernel is based on FreeBSD and Mach 3.0
technologies and provides protected memory and pre-emptive multitasking."
While I don't have the patience to wade through Apple's site, the
GNU-Darwin distribution uses pkg_add.  (So that'd be a "yes" to your last
question.)

-- 
Jonathon Isaac Swiderski \\ dangercat-20@dangercat.net
cs.oberlin.edu/~jswiders  \\  www.dangercat.net/resume

For every problem there is one solution which is simple, neat, and wrong.
-- H. L. Mencken

Re: Software/HD ecology

[Kai Großjohann]

Jonathon Isaac Swiderski <jonswid@umich.edu> writes:

> On Tue, 17 Dec 2002, Kai Großjohann wrote:
>
>> Alas, the Unix crowd appears to follow the Perl
>> philosophy `There is more than one way to do it', and hence, different
>> Unices have different ways.
>
> You've your history backwards--- UNIX predates Perl by better than ten
> years.

Sorry, I didn't mean to imply any causality.  Maybe I should have said
that both follow the same philosophy.  Got to be careful with my
phrasing.

I know that Unix is older than Perl :-)

> Much of the duplication of functionality in UNIX comes from the
> SysV/Berkeley split.

Hm.  Can't really say much about it.  But it seems to me that there is
more to it than that.  Consider the output of "netstat -ntl" on my
GNU/Linux system:

/----
| kai@lucy> netstat -ntl
| Active Internet connections (only servers)
| Proto Recv-Q Send-Q Local Address           Foreign Address         State
| tcp        0      0 0.0.0.0:992             0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:867             0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:37              0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:999             0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:9               0.0.0.0:*               LISTEN
| tcp        0      0 172.16.117.1:139        0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:13              0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:113             0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
\----

Suppose I wanted to know the list of local addresses listened to.  If
you ask Peter, he'll say

    netstat -ntl | awk '$1 == "tcp" { print $4 }'

If you ask Paul, he'll say

    netstat -ntl | tail +3 | tr -s ' ' | cut -d' ' -f4

If you ask Larry, he'll say something involving Perl, and I'm sure
there are many other possibilities.  If you ask my old friend Michael,
who's a lex fan, he'd write a lexer for this, I'm sure.

Then there is

    netstat -ntl | ( \
        read a; read a
        while read prot recv send loc for state; do
          echo $loc
        done )

which I haven't tested, but something like this probably works, as
well.

I think this is not really a BSD versus SysV issue.  It's just that
Unix provides many tools which can be combined in various ways.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Kai" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:

    Kai> Yes, indeed.  Alas, the Unix crowd appears to follow the Perl
    Kai> philosophy `There is more than one way to do it', and hence,
    Kai> different Unices have different ways.

I  consider  this a  good  phenomenon.   It  is how  evolution  works:
varieties created  by crossing over and mutation;  the unsuitable ones
eliminated  by natural  selection.  So,  with time,  the  system would
evolve to an optimum.


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Kai Großjohann]

Lee Sau Dan <danlee@informatik.uni-freiburg.de> writes:

> I  consider  this a  good  phenomenon.   It  is how  evolution  works:
> varieties created  by crossing over and mutation;  the unsuitable ones
> eliminated  by natural  selection.  So,  with time,  the  system would
> evolve to an optimum.

Well, err.  How come I doubt this.  Maybe I can't see the wisdom of
the outcome of a similar process regarding operating systems and one
regarding office software...

If Autoconf would make it easy for people to install an uninstaller,
then a change to the technically better might happen.  But I don't
think that the world is going to standardize on a package format
anytime soon.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Alfred M. Szmidt]

   If Autoconf would make it easy for people to install an uninstaller,
   then a change to the technically better might happen.  But I don't
   think that the world is going to standardize on a package format
   anytime soon.

Well, it already sort of has.  The "package format" is called
auto{conf,make}. :-)

Re: Software/HD ecology

[Ajanta]

Lee Sau Dan <danlee@informatik.uni-freiburg.de> wrote:

> 'man rpm', if you're on a RedHat or SuSE system.

As you could perhaps guess from the Newsgroups line, the specific
systems we were discussing are Mac OS X and BSD's. Or we could discuss
all Unix-like systems in general. They don't have "rpm". From your
statement, it would seem it is not even a Linux syandard, just
something that comes with two packages?

Re: Software/HD ecology

[jdf23]

Lee Sau Dan <danlee@informatik.uni-freiburg.de> wrote:

>     Anil> I think unix was conceptualized for small systems and
>     Anil> programs, where a user might know every file, where it came
>     Anil> from, what it does. 
> 
> Wrong.  Unix  has been designed  to be a  multi-concurrent-user system
> since  3 decades  ago.   Unix  systems used  to  be time-shared  among
> hundreds (in some cases thousands) of concurrent users.  Normally, the
> end users only  know about a few subtree of  the whole directory tree,
> and that's enough for his work.

Your sense of history is different. Some of us remember when you
couldn't find "hundreds" of people who knew what unix was, and in unix
at least, end users and beginning users were the same people. Even when
hundreds of users materialized, they didn't have FSF to download
programs from.

> That why we hav package management tools, like RPM on RedHat and SuSE.

Good for Red Hat and SuSE. Has it occured to you that there are other
flavors of Linux, other versions of Unix, not to forget Mac OS X since
the lead newsgroups in this thread are Mac groups?

>     Anil> Shouldn't you be able to know just what a particular file
>     Anil> named "dtabttf" doing on your system?  
> Unix programmers would have used a more descriptive filenames.

Merely from looking at their names, I certainly can't always decipher
what many of the unix files do. Nor can I always guess which program
they might come form.

> rpm -qf /etc/ntpd.conf

No good on most Unix or even Linux systems.

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "jdf23" == jdf23  <jdf23@some.email> writes:

    >> That why we hav package management tools, like RPM on RedHat
    >> and SuSE.

    jdf23> Good for Red Hat and SuSE. Has it occured to you that there
    jdf23> are other flavors of Linux, other versions of Unix, 

Why not?  I started my "Unix life" with primarily SunOS, but also used
DEC unix, HPUX, IRIX and AIX from time to time.  I had Minix on my own
PC, and then  Linux.  I've used a few  Linux distributions: Slackware,
RedHat,  SuSE.  Despite the  differences, they're  all similar  to one
another.  Once  you've grasped the  basic principles, it's so  easy to
context-switch between these  Unices.  Actually, I used to  open a few
X-clients  from a  few different  platforms (DEC,  SunOS/Solaris, AIX,
IRIS) to  a single  X-server at the  same time.   And I don't  have to
really tell the differences between them.


    jdf23> not to forget Mac OS X since the lead newsgroups in this
    jdf23> thread are Mac groups?

Only played  Macs for brief  sessions of under  1 hour in the  past 15
years.


    Anil> Shouldn't you be able to know just what a particular file
    Anil> named "dtabttf" doing on your system?
    >> Unix programmers would have used a more descriptive filenames.

    jdf23> Merely from looking at their names, I certainly can't
    jdf23> always decipher what many of the unix files do. Nor can I
    jdf23> always guess which program they might come form.

    >> rpm -qf /etc/ntpd.conf

    jdf23> No good on most Unix or even Linux systems.

Of course, you have to be  familiar with the package manager.  But why
not?


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> I wasn't aware of this and will have to look into it. However, unless a
> program's creators cooperate, I can't visualize how stow would prevent
> a program from installing files all over the place leaving you with no
> way to uninstall?

No, stow needs the cooperation of the packages.  But for the packages
I have seen it is usually trivial to tell them to install themselves
into a specific directory.

The stow documentation also gives some advice on installing packages
so that they work well with it.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[David Masterson]

>>>>> Kai Großjohann writes:

> Ajanta <ajanta@no.spam> writes:

>> I wasn't aware of this and will have to look into it. However,
>> unless a program's creators cooperate, I can't visualize how stow
>> would prevent a program from installing files all over the place
>> leaving you with no way to uninstall?

> No, stow needs the cooperation of the packages.  But for the packages
> I have seen it is usually trivial to tell them to install themselves
> into a specific directory.

All programs (that I know of) install their files into a directory
structure of some sort.  With GNU programs, the top of that directory
structure is usually /usr/local, but it's usually possible to install
it elsewhere.  Stow (and Pkglink) make use of that ability.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:

    Ajanta> I wasn't aware of this and will have to look into
    Ajanta> it. However, unless a program's creators cooperate, I
    Ajanta> can't visualize how stow would prevent a program from
    Ajanta> installing files all over the place leaving you with no
    Ajanta> way to uninstall?

Why in  the first place  would the program  NEED to install  files all
over the place?

Unix  is  well  designed.  Most  (if  not  all)  GNU programs  can  be
configured   to   be   installed   anywhere  (usually   defaulted   to
/usr/local/foobar) and  run off there  directly.  There is no  need to
install files every here and  there.  That another popular inferior OS
does it doesn't mean Unix has to use the same approach.

To uninstall  the application,  simply "rm -rf  /usr/local/foobar" and
you're done!


You may have PATH or paths  to libraries in mind.  Unix has an elegant
tool: symbolic  links.  That other  popular inferior OS tried  to copy
this feature, but  didn't do it properly.  Short-cuts  simply a broken
way  of implementing  symlinks.  With  symlinks,  we place  a link  in
/usr/bin   or  /usr/local/bin   to   point  to   the  executables   in
/usr/local/foobar.  Similarly  for libraries.  After  uninstalling the
program, these  symlinks would become dangling and  hence unusable.  A
simple "find / -lname  "/usr/local/foobar/*" |xargs rm -f" would clean
them.


Anyway, nowadays,  people almost always use package  managers, such as
RPM in RedHat  and SuSE.  These are software systems  to keep track of
installed  files.  They  provide an  easy way  to  uninstall packages,
keeping an eye on the package dependencies.



    Ajanta> A practical problem is that except perhaps to an insider
    Ajanta> most names are unintuitive. If a file is named emacs-foo
    Ajanta> or foo.el you can guess what it is but a name like
    Ajanta> zuplibfoo (this is hypothetical, but most unix names have
    Ajanta> similar transparency) doesn't tell you which of the
    Ajanta> hundreds of packages it might belong to. So you can't even
    Ajanta> try to uninstall everything manually.

That explains why the issue you  raised out is a non-problem for Unix.
Unix  has been  supporting  long file  names  for a  long time.   Unix
programmers tend to use more verbose and descriptive filenames, rather
than  thinks like  PROGRA~1.   So, we  normally  don't such  problems.
Moreover, as  mentioned above, we tend  to put files of  each app into
its own  directory and then  install symlinks in /usr/bin,  instead of
sprinkling files here and there.


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Ajanta]

Lee Sau Dan <danlee@informatik.uni-freiburg.de> wrote:

> Why in the first place would the program NEED to install files all
> over the place?

It doesn't, shouldn't, but many do.
 
> Unix  is  well  designed.  Most  (if  not  all)  GNU programs  can  be
> configured   to   be   installed   anywhere...

The complaint in this sub-thread is that many times programs come with
bad default choices. Often, to compound the problem, there is no
uninstall. This is not about Unix, but people who write, manage, or
distribute programs. I used the term unix to refer to the community and
its culture, not the OS.

> To uninstall  the application,  simply "rm -rf /usr/local/foobar" and
> you're done!

Here is the example a poster gave from his system. There may or may not
be other emacs related named files there, these are just the matches on
the *name* emacs:

   % find /usr -name emacs -print
   /usr/bin/emacs
   /usr/info/emacs
   /usr/libexec/emacs
   /usr/local/bin/emacs
   /usr/share/emacs
   /usr/share/info/emacs

To duplicate the convenience implied in your suggestion, one would have
to delete /usr.

> Anyway, nowadays,  people almost always use package  managers, such as
> RPM in RedHat and SuSE.

To have package managers which work on only one or two sub-flavors or,
as in Fink's case, only on the software downloaded from one source is
really not such a hot solution (though a welcome "patch").

What is needed: 

(1) To change the culture, so that every program comes with a safe and
complete uninstall option. 

(2) To empower the user, so he/she can easily discover what a
particular file on his/her computer is for, and where are all the files
related to the package xyz. I think you want to be able to specify the
source (GNU or FSF), name (emacs), and version (27.5) with intelligent
defaults, like all versions when none is specified.

> That explains why the issue you  raised out is a non-problem for Unix.
> Unix  has been  supporting  long file  names  for a  long time.

I haven't come across many programs with long descriptive file names.
However, I'll avoid this direction because I view it as less relevant.
I want precise and reliable tools to know what a file was for. I don't
want to guess such things from names. 

A

Re: Software/HD ecology

[Tribhuvan]

Ajanta wrote:


> What is needed: 
> 
> (1) To change the culture, so that every program comes with a safe and
> complete uninstall option. 
> 
> (2) To empower the user, so he/she can easily discover what a
> particular file on his/her computer is for, and where are all the files
> related to the package xyz. I think you want to be able to specify the
> source (GNU or FSF), name (emacs), and version (27.5) with intelligent
> defaults, like all versions when none is specified.
> 

pkg managers are an ideal model dealing with installing
binaries, logging the multiple cp operations, version
install date to /var.
This allows for on demand reporting on all of the files
that were copied to the system and their subsequent
removal (or 'management' as the name pkg manager implies.)

Only, this is absent when installing from source.
When done compiling and doing "make install" according to
your ./configure options, the output of "make install"
has scrolled off conveniently to bit heaven. Thus, gaining
lots of control over the _install_ process, we usually suffer
later, not having a record of where everything went.
If you're the only sys admin to ever touch the machines,
and your memory is that good, well - there's got to be a
better way. Just as the wonderful standards that have
come to place during the _install_ process (aka automake,
autoconf, pkgconfig (ala gnome)), would it really be
too far out to suggest:

* The relevant output of 'make install' be systematically
* captured and stored to something like
* (/var/log/auto-conf/pkg.version.log). Then, this formatted log
* can be fed to another relatively simple script to report on or
* operate on said files.

* To work, those involved with distributing source may standardize
* their make-install output to contain flags to be read by a piped
* script, which will capture the relatively few lines relevant
* to any subsequent package management.

Tribhuvan

Re: Software/HD ecology

[Kai Großjohann]

Tribhuvan <loka@rcn.com> writes:

> Only, this is absent when installing from source.
> When done compiling and doing "make install" according to
> your ./configure options, the output of "make install"
> has scrolled off conveniently to bit heaven.

You could try "make -n uninstall > /tmp/foo" right after "make
install".  Maybe then /tmp/foo contains the necessary info.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[David Masterson]

>>>>> Kai Großjohann writes:

> Tribhuvan <loka@rcn.com> writes:

>> Only, this is absent when installing from source.  When done
>> compiling and doing "make install" according to your ./configure
>> options, the output of "make install" has scrolled off conveniently
>> to bit heaven.

> You could try "make -n uninstall > /tmp/foo" right after "make
> install".  Maybe then /tmp/foo contains the necessary info.

Exactly.  My contention is that /tmp/foo should be installed right
along with everything else.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Miles Bader]

David Masterson <dmaster@synopsys.com> writes:
> > You could try "make -n uninstall > /tmp/foo" right after "make
> > install".  Maybe then /tmp/foo contains the necessary info.
> 
> Exactly.  My contention is that /tmp/foo should be installed right
> along with everything else.

... and also wrote in a different message:
> 2. To allow for source removal, "make install" should install an
>    uninstaller (like this: "make -n uninstall > uninstaller; install
>    uninstaller").

Those seem like pretty reasonable ideas; in more concrete form, perhaps
they could be added to the GNU programming standards or something.

E.g.:

  * What would the `/tmp/foo' file be called really?
    Something like `/usr/share/foo/files'?

  * What would the uninstaller program be called?
    [Presumably uninstall-PACKAGE]

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: Software/HD ecology

[Fredrik Staxeng]

Miles Bader <miles@gnu.org> writes:

>Those seem like pretty reasonable ideas; in more concrete form, perhaps
>they could be added to the GNU programming standards or something.

I think that right thing is a gnu-install program. This would be
called from install targets in the makefiles. It would log the
files installed, and then you could do gnu-uninstall emacs.

It could make backups of any files overwritten, allow only files 
owned by this package to be overwritten, collect checksums so
that modified files can be identified, generate file lists for
binary distributions.

It should support files, directories and symlinks. It could support
postactions such as running makewhatis after a man page is installed.
If it setuid-safe one could make two users, gnubin and gnusource,
and use file protections to verify that the installation action behaves.

The configure scripts should already be looking for BSD install,
and use that for installing the all the files. The configure script
is generated by autoconf, which gives a single point for introducing
this with a minimum of effort for the maintainers of GNU packages.

I think that undo logic has to be derived automatically. Manually
writing things like that too error-prone, especially if they need 
ongoing maintenance.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: Software/HD ecology

[Peter S Galbraith]

Fredrik Staxeng <fstx+u@update.uu.se> wrote:

> Miles Bader <miles@gnu.org> writes:
> 
> >Those seem like pretty reasonable ideas; in more concrete form, perhaps
> >they could be added to the GNU programming standards or something.
> 
> I think that right thing is a gnu-install program. This would be
> called from install targets in the makefiles. It would log the
> files installed, and then you could do gnu-uninstall emacs.
> 
> It could make backups of any files overwritten, allow only files 
> owned by this package to be overwritten, collect checksums so
> that modified files can be identified, generate file lists for
> binary distributions.
> 
> It should support files, directories and symlinks. It could support
> postactions such as running makewhatis after a man page is installed.
> If it setuid-safe one could make two users, gnubin and gnusource,
> and use file protections to verify that the installation action behaves.

Some people have said that package managers don't solve the problem for
everyone.  But anyone embarking on coding a new `gnu-install' program
should see these packagers as prior art and study them first.  They
pretty much do all of the above already!

Peter

Re: Software/HD ecology

[Fredrik Staxeng]

Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:

>Some people have said that package managers don't solve the problem for
>everyone.  But anyone embarking on coding a new `gnu-install' program
>should see these packagers as prior art and study them first.  They
>pretty much do all of the above already!

They do, but package managers support the packages. This way would be 
the other way around, the packages support the package maintainer.
How many packages out there come with the debian/* files or the
*.rpmspec file, maintained by the original package maintainer?

This is similar to one of the big differences between Linux and Windows.
Linux supports the hardware, but the hardware supports Windows. 

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: Software/HD ecology

[David Masterson]

>>>>> Peter S Galbraith writes:

> Some people have said that package managers don't solve the problem
> for everyone.  But anyone embarking on coding a new `gnu-install'
> program should see these packagers as prior art and study them
> first.  They pretty much do all of the above already!

Which is a reason to avoid making this overly complex.  If you're
going to do something that amounts to package management, then use a
package manager.  All that's needed here is the list of things that
got installed via "make install" so that it may easily be uninstalled
later.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Miles Bader]

Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> But anyone embarking on coding a new `gnu-install' program
> should see these packagers as prior art and study them first.

The proposed functionality is much, much, less ambitious than a typical
package manager.  Really it doesn't do anything more than the current
`make uninstall', it just puts the information in a more handy form,
and allows the user to get rid of the original source/build tree.

People who want real package management can use a real package manager
of their choice.

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Software/HD ecology

[Alfred M. Szmidt]

   It should support files, directories and symlinks. It could support
   postactions such as running makewhatis after a man page is installed.
   If it setuid-safe one could make two users, gnubin and gnusource,
   and use file protections to verify that the installation action behaves.

Small side note of an obscure automake feataure.  One can run scripts
after the install process by supplying the POST_UNISTALL variable with
a file-name.  There are other such variables like PRE_INSTALL,
PRE_UNINSTALL etc.  Read the Makefile.in's for more information. ;-)

Re: Software/HD ecology

[Miles Bader]

Fredrik Staxeng <fstx+u@update.uu.se> writes:
> >Those seem like pretty reasonable ideas; in more concrete form, perhaps
> >they could be added to the GNU programming standards or something.
> 
> I think that right thing is a gnu-install program. This would be
> called from install targets in the makefiles. It would log the
> files installed, and then you could do gnu-uninstall emacs.

The GNU coding standards in general do not presume any external
non-standard dependencies -- that is, everything they say can
theoretically be accomplished given only the package in question -- and
specify _what_ you should do rather than the mechanism by which you
should do it.

So certain package might want to use a `gnu-install' program that does
the book-keeping for them to meet the coding standards, but they'd have
to have their own copy of that program in their distribution (though
they needn't actually use it if their configure script detects a native
version).  Other packages may choose to simply do it another way.

It might be useful for users to have a `gnu-uninstall' program, but such
a thing should be an optional additional package that uses the basic
information provided by each package, as specified by coding standards.

> I think that undo logic has to be derived automatically. Manually
> writing things like that too error-prone, especially if they need 
> ongoing maintenance.

That's true, and maybe this would mean that most packages would end up
using a standard `gnu-install' program/script -- but it should be up to
the package to decide.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Software/HD ecology

[Fredrik Staxeng]

Miles Bader <miles@gnu.org> writes:

>Fredrik Staxeng <fstx+u@update.uu.se> writes:
>> >Those seem like pretty reasonable ideas; in more concrete form, perhaps
>> >they could be added to the GNU programming standards or something.
>> 
>> I think that right thing is a gnu-install program. This would be
>> called from install targets in the makefiles. It would log the
>> files installed, and then you could do gnu-uninstall emacs.
>
>The GNU coding standards in general do not presume any external
>non-standard dependencies -- that is, everything they say can
>theoretically be accomplished given only the package in question -- and
>specify _what_ you should do rather than the mechanism by which you
>should do it.

Yes, coding standards do not, on their own, actually do anything. 
The addition to the coding standards would be "the configure script
should check for the existence of gnu-install". 

>So certain package might want to use a `gnu-install' program that does
>the book-keeping for them to meet the coding standards, but they'd have
>to have their own copy of that program in their distribution (though
>they needn't actually use it if their configure script detects a native
>version).  Other packages may choose to simply do it another way.

I was think more, "if you want uninstall functionality, install gnu-install
first". Perhaps the biggest packages should require it, and therefore
include it in the distribution. But it would be overkill for gzip.

>It might be useful for users to have a `gnu-uninstall' program, but such
>a thing should be an optional additional package that uses the basic
>information provided by each package, as specified by coding standards.

I think the other way around is more practical, that the packages
directly support gnu-install. 

Perhaps I have not made the mechanism clear. The idea was the makefile
calls "gnu-install package version file dest", instead of install.sh
or BSD install. This is a simple extension of what is already done
today. 

>> I think that undo logic has to be derived automatically. Manually
>> writing things like that too error-prone, especially if they need 
>> ongoing maintenance.
>
>That's true, and maybe this would mean that most packages would end up
>using a standard `gnu-install' program/script -- but it should be up to
>the package to decide.

I would like to be able to force packages to use a tool that I trust. 
If it is easy enough to do, I would implement support for it and send
patches to the maintainer.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: Software/HD ecology

[Tribhuvan]

Fredrik Staxeng wrote:

> Yes, coding standards do not, on their own, actually do anything. 
> The addition to the coding standards would be "the configure script
> should check for the existence of gnu-install". 

Which doesn't at all get in the way of anyone who does not want
to implement gnu-install

 > I would like to be able to force packages to use a tool that I trust.
 > If it is easy enough to do, I would implement support for it and send
 > patches to the maintainer.

If it's kept to basically to:
    1) logging the cp operations of `make install`
    2) providing a script to remove part or all of what's in the log
It shouldn't get too monsterous.

Re: Software/HD ecology

[Miles Bader]

Fredrik Staxeng <fstx+u@update.uu.se> writes:
> Perhaps I have not made the mechanism clear. The idea was the makefile
> calls "gnu-install package version file dest", instead of install.sh
> or BSD install. This is a simple extension of what is already done
> today.

No, it's completely obvious what you meant; it's just that you're
over-specifying.  Such implementation details are up to the package
maintainers.

Similarly, the coding standards _don't_ say `you should use autoconf to
make a configure script' (even though that's certainly one of the best
ways to do it, and how it's almost always done), they just say `you
should have a configure script.'

> I would like to be able to force packages to use a tool that I trust. 
> If it is easy enough to do, I would implement support for it and send
> patches to the maintainer.

If you personally don't want to trust anything that doesn't use a
`gnu-install' script, you're free to only use packages that do.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: Software/HD ecology

[Fredrik Staxeng]

Miles Bader <miles@gnu.org> writes:

>Fredrik Staxeng <fstx+u@update.uu.se> writes:
>> Perhaps I have not made the mechanism clear. The idea was the makefile
>> calls "gnu-install package version file dest", instead of install.sh
>> or BSD install. This is a simple extension of what is already done
>> today.
>
>No, it's completely obvious what you meant; it's just that you're
>over-specifying.  Such implementation details are up to the package
>maintainers.

My proposal is for an external facility, and that packages check for
it and use it if available. I think that the main feature of the 
proposal is that it places minimal burden on the package maintainers.

I think that requiring working uninstall targets places a bigger burden
on package maintainers.

>From the gcc-3.2 Makefile:

uninstall:
        @echo "the uninstall target is not supported in this tree"

>Similarly, the coding standards _don't_ say `you should use autoconf to
>make a configure script' (even though that's certainly one of the best
>ways to do it, and how it's almost always done), they just say `you
>should have a configure script.'

Autoconf is one of those things that only get reinvented by people
who don't understand how much work went into making it in the first
place. I would go a bit further than saying that it is the best way,
I think its the only reasonable way. I think the coding standards
could recommend autoconf a bit more strongly that they do today.

There is nothing in my proposal that requires autoconf. It merely
makes it easier to implement support for it. 

>> I would like to be able to force packages to use a tool that I trust. 
>> If it is easy enough to do, I would implement support for it and send
>> patches to the maintainer.
>
>If you personally don't want to trust anything that doesn't use a
>`gnu-install' script, you're free to only use packages that do.

I always do "make -n install" to see what the package wants to install.
Partly because of curiosity, I want to know where it puts things, 
and what those things are. But of course, there is the suspicion
that it might do something bad. It has happened in the past, it will
happen again. (This does not imply malice on any part, of course)

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: Software/HD ecology

[David Masterson]

>>>>> Fredrik Staxeng writes:

> I think that requiring working uninstall targets places a bigger
> burden on package maintainers.

It really shouldn't be.  The generated Makefile already knows what the
list of files are that it wants to install and where it wants to
install them.  Therefore, the uninstall target should be:

        uninstall:
                for x in $(TARGETS); do \
                        $(RM) $(TARGET_DIR)/$$x; \
                done

You may need to duplicate the loop for each TARGET_DIR.  It should be
trivial for automake to generate that in its Makefiles.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[David Masterson]

>>>>> Miles Bader writes:

> Those seem like pretty reasonable ideas; in more concrete form,
> perhaps they could be added to the GNU programming standards or
> something.

Or autoconf/automake...

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Tribhuvan]

David Masterson wrote:

> Or autoconf/automake...
> 

 >> You could try "make -n uninstall > /tmp/foo" right after "make
 >> install".  Maybe then /tmp/foo contains the necessary info.

 >Exactly.  My contention is that /tmp/foo should be installed right
 >along with everything else.

Just how commonly available is the "make -n uninstall > /tmp/foo"
in src distributions anyway. Actually, because of my ignorance
of it I never used it. If it is widely incorporated, then it
may be a matter of putting an option in ./configure like:
--enable-uninstall=/tmp/foo (or /var/pkg/foo)
which would be comparatively easier than developing a
pkg-manager which is really an OS dependent thing anyway.

The configure option could trigger the "make -n uninstall" command
to occur right after "make install" - and would increase
awareness of the option by placing it in an obvious place
(via: ./configure --help).

Re: Software/HD ecology

[David Masterson]

>>>>> Tribhuvan  writes:

> David Masterson wrote:

>> Or autoconf/automake...

>>> You could try "make -n uninstall > /tmp/foo" right after "make
>>> install".  Maybe then /tmp/foo contains the necessary info.

>> Exactly.  My contention is that /tmp/foo should be installed right
>> along with everything else.

> Just how commonly available is the "make -n uninstall > /tmp/foo"
> in src distributions anyway. 

The point is that the installation of a "/tmp/foo" isn't available in
any of the GNU applications (AFAIK) although many have a "make
uninstall".  Kai's suggestion was that, therefore, it's easy to hand
create an uninstaller.  My suggestion is that "make install" should
then do it and autoconf/automake should be updated to incorporate this
in the Makefiles that they generate.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Tribhuvan]

David Masterson wrote:

>>>Exactly.  My contention is that /tmp/foo should be installed right
>>>along with everything else.

>  My suggestion is that "make install" should
> then do it and autoconf/automake should be updated to incorporate this
> in the Makefiles that they generate.

After doing `make` the Makefile should contain the data on
which items will be installed where during `make install`.
  (if i understand correctly).

If autoconf/automake incorporate a routine to:

  At the tail end of `make` - extract the file names and paths
  from the Makefile to a "file_list.dat" within the source tree.
  The textfile in turn could be copied to somewhere on the
  system during `make install` (to a location specified during
  `configure`).
  this "file_list.dat" can be used later by another (new) automake
  routine to remove files from the system.

Re: Software/HD ecology

[Tribhuvan]

Excuse the double post -

1) existing distribution_speific_package_managers <and>
    creating "package management" for gnu_from_source
    are two different things: one exists, one does not.

2) if people feel that this thread (which started as an
    emacs issue) should vacate this newsgroup pls suggest
    a better forum... ;^)

Re: Software/HD ecology

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

>   * What would the `/tmp/foo' file be called really?
>     Something like `/usr/share/foo/files'?
>
>   * What would the uninstaller program be called?
>     [Presumably uninstall-PACKAGE]

Note that my /tmp/foo and the uninstaller would have the same
contents.

I suggest that uninstall-PACKAGE be installed to the same directory as
the other binaries from that package.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Alfred M. Szmidt]

Why not just extend automake to support an install-stow target that
installs packages in $(prefix)/package/PACKAGE/VERSION by default?

Then one can use stow to install the package, remove the symlinks it
created.  And remove the whole package with a simple rm.  One can also
extened automake to support installing an .depend file that lists
possible dependecies.  Programs can then use this to calculate if the
program will work or not.  And on GNU/Hurd a package translator could
read this file and "install" them in /.

Enough rambling for one day. ;)

Re: Software/HD ecology

[David Masterson]

>>>>> Alfred M Szmidt writes:

> Why not just extend automake to support an install-stow target that
> installs packages in $(prefix)/package/PACKAGE/VERSION by default?

Because not everyone wants to use stow (or any package manager).
Besides, you can configure the 'prefix' to what you're suggesting
above if you want to use stow, so there is nothing to change in
automake for it.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Alfred M. Szmidt]

   > Why not just extend automake to support an install-stow target that
   > installs packages in $(prefix)/package/PACKAGE/VERSION by default?

   Because not everyone wants to use stow (or any package manager).

One is not forced to use stow, one can use anything.  But since
autoconf is designed for GNU it should be designed to fit in with
other GNU tools.  You can still for example use the normal install
target todo the traditional thing, or use some other program that
conforms to the install-stow practise.

   Besides, you can configure the 'prefix' to what you're suggesting
   above if you want to use stow, so there is nothing to change in
   automake for it.

Configuring with the prefix variable is discouraged.  For example if a
program is configured to look for files in
$(prefix)/package/foo/0.1/share/foo, and another program installs
files in $(prefix)/package/bar/0.2/share/foo/bar-extra.  Then the
package foo will never find these files since it does not look in
$(prefix)/share/foo (assuming it was stowed to /).  One should
configure with the normal prefix options and then use DESTDIR when
running the install target.  Sadly not all GNU packages support this
since it is not mandated by the GNU Coding standard.

Anyway, isn't this highly off-topic for help-gnu-emacs?

Re: Software/HD ecology

[Miles Bader]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
> >   * What would the `/tmp/foo' file be called really?
> >     Something like `/usr/share/foo/files'?
> >
> >   * What would the uninstaller program be called?
> >     [Presumably uninstall-PACKAGE]
> 
> Note that my /tmp/foo and the uninstaller would have the same
> contents.

Oh, true; I was thinking of a list of files installed by `make install'.

Actually, I think both pieces of information are useful --
one answers the question `What files did package FOO install?'
(which I find myself asking quite a lot actually, though since I'm using
debian I usually I can just use `dpkg -L' to find out), and the other
provides an way to automatically uninstall the package (this _usually_
will be the same as `cat LIST-OF-FILES | xargs rm -f', but for complicated
packages, may not be).

> I suggest that uninstall-PACKAGE be installed to the same directory as
> the other binaries from that package.

That's good, I think.

What about the LIST-OF-FILES though?

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: Software/HD ecology

[Tribhuvan]

> 
>>I suggest that uninstall-PACKAGE be installed to the same directory as
>>the other binaries from that package.
> 
> 
> That's good, I think.
> 
> What about the LIST-OF-FILES though?
> 
> -Miles

If something like this could be done in configure:

configure --with-uninstall=/var/log/gnu/installed/PACKAGE.VERSION.log

Then anyone can generate their own style of LIST-OF-FILES naming.

And, if this formatted LIST file could be used by a script like:

  # sh uninstall.sh < /var/log/gnu/installed/PACKAGE.VERSION.log
  ...removing package-foo
  remove all pkg-foo files from /opt/sfw/bin [y|n|?]:
  remove all pkg-foo files from /opt/sfw/etc [y|n|?]:
  ...and so on.

or simply:
cat LIST-OF-FILES

Re: Software/HD ecology

[Fredrik Staxeng]

Miles Bader <miles@gnu.org> writes:

>Actually, I think both pieces of information are useful --
>one answers the question `What files did package FOO install?'

Or which package installed file bar?

>(which I find myself asking quite a lot actually, though since I'm using
>debian I usually I can just use `dpkg -L' to find out), and the other
>provides an way to automatically uninstall the package (this _usually_
>will be the same as `cat LIST-OF-FILES | xargs rm -f', but for complicated
>packages, may not be).

That would be dangerous. Another package might have overwritten some of
the files. Of course, my gnu-install program could check if existing
files are owned by this package, and do something clever and undoable
if it belongs to another.

>> I suggest that uninstall-PACKAGE be installed to the same directory as
>> the other binaries from that package.
>
>That's good, I think.
>
>What about the LIST-OF-FILES though?

For my proposal, that information should probably be kept in dbm-files.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Kai" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:

    Kai> You could try "make -n uninstall > /tmp/foo" right after
    Kai> "make install".

This would  not work  if the "make  uninstall" is invoking  some shell
scripts or  programs that are only  found in the source  tree, not the
installed by "make install".

Actually, I'm quite frustrated  that nowadays, "make -n install" won't
even  give you  any clue  of what  will be  done.  It's  just  a dozen
multi-line shell  commands to  invoke a ton  of other things,  often a
"./install-files" script distributed with the source.


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Tribhuvan]

Lee wrote:
 > make install 2>&1 >install.log

Redirecting the output to a log file is useful, and
should be a standard practice, but as I indicated in
an earlier post, only a very small portion of this output
indicates the copy operations. In particular, the bin,
lib, man, share portions of an installation. (/etc and
/var stuff I don't think should be removed automatically
during an uninstall because these locations should contain
your custom configuration files and log files which may be
useful later). An install prefix like
--prefix=/usr/local/package
would be problematic for production environments as there
are security and sanity issues that prevent us from mixing
various types of files and directories on any disk partition.

 > ...a "make installed_file_list"...would be very helpful.
 > Or a "make uninstall.sh"...undoing whatever "make install" has done.

I was originally thinking of capturing/filtering the output of
"make install", but you may be on to something much more practical.

After doing "make", all of the instructions are prepared
for "make install". The same set of instructions could be
used for a "make installed" (<- truncated name) to generate
an "installed_file_list". Once this little database is created,
a relatively simple shell script could perform something like:

# make installed > /var/gnu/package-foo.installed_list.log
# sh uninstall.sh < /var/gnu/package-foo.installed_list.log
...removing package-foo
remove all pkg-foo files from /opt/sfw/bin [y|n|?]:
remove all pkg-foo files from /opt/sfw/etc [y|n|?]:
...and so on.

only, if "uninstall.sh" were a standardized item (and) not
something that might inadvertantly get deleted along with
the source tree.

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Tribhuvan" == Tribhuvan  <loka@rcn.com> writes:

    Tribhuvan> Only, this is absent when installing from source.  When
    Tribhuvan> done compiling and doing "make install" according to
    Tribhuvan> your ./configure options, the output of "make install"
    Tribhuvan> has scrolled off conveniently to bit heaven. 

Next, time, try:

        make install 2>&1 >install.log


    Tribhuvan> * The relevant output of 'make install' be
    Tribhuvan> systematically * captured and stored to something like

Yeah!  I agree.  I'd like a "make installed_file_list", which would be
very helpful.  Or a "make uninstall.sh", which automatically generates
a *independent*  shell script for undoing whatever  "make install" has
done.




-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[David Masterson]

>>>>> Peter S Galbraith writes:

> Ajanta <ajanta@no.spam> wrote:

>> To have package managers which work on only one or two sub-flavors

> Sub-flavors of what?  Unix?  Well these tools are free, so adapt
> them to your flavor.  

That's not a solution.  For instance, if a package does not come in
RPM form, then the RPM package manager is not a solution for me.  Are
you expecting all packages to distribute in a form that is compatible
to all package managers so that they can be managed on all systems?

GNU tools generally are not distributed with any package manager in
mind.  They have "make install" and some have "make uninstall" as the
replacement for a package manager.  MS-Windows actually has this issue
well handled.  They have one package manager (although there is
probably version issues) and every package (supposedly) installs the
necessary information for uninstalling itself via the package manager.
All that is needed in the GNU tools (like Emacs) is a "make install"
that also installs an uninstaller.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Tribhuvan]

David Masterson wrote:
   Are
> you expecting all packages to distribute in a form that is compatible
> to all package managers so that they can be managed on all systems?
> 

I think this brings to light that:

If you're getting a binary dist pkg, by default you get management
for your OS, which means you lose control on the install process.
Therefore, we really only need focus on standards for gnu/fsf source
distributions.

Tribhuvan

Re: Software/HD ecology

[Kai Großjohann]

David Masterson <dmaster@synopsys.com> writes:

> That's not a solution.  For instance, if a package does not come in
> RPM form, then the RPM package manager is not a solution for me.

It seems that the "checkinstall" tool might help.  Doing "checkinstall
make install" will do whatever "make install" does and create an RPM
from it.  (Actually, it asks you whether you want *.deb or *.rpm or a
Slackware package.)

Nifty.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[David Masterson]

>>>>> Kai Großjohann writes:

> David Masterson <dmaster@synopsys.com> writes:

>> That's not a solution.  For instance, if a package does not come in
>> RPM form, then the RPM package manager is not a solution for me.

> It seems that the "checkinstall" tool might help.  Doing
> "checkinstall make install" will do whatever "make install" does and
> create an RPM from it.  (Actually, it asks you whether you want
> *.deb or *.rpm or a Slackware package.)

Nah.  That's really for the O/S distributions to do (or anyone who's
attempting to create a "package").  I'm merely suggesting two things:

1. If a program can do a "make install", it should have a "make
   uninstall" to go with it.  
2. To allow for source removal, "make install" should install an
   uninstaller (like this: "make -n uninstall > uninstaller; install
   uninstaller").

I've worked on UNIX distributions that don't use things like RPM, DEB,
and so on.  That was okay as all I wanted to do was download the
program, configure it, install it, and remove the excess (source).  At
some point in the future, I (or my successor) might want to remove the
installed program.  That's where having an uninstaller in #2 to
unambiguously list what needs removing comes in.

This is probably more of a GNU tools (autoconf/automake) issue, but
GNU Emacs has in the past used a highly hacked configure tool (does it
still?), so it might apply here as well.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Kai Großjohann]

David Masterson <dmaster@synopsys.com> writes:

> 2. To allow for source removal, "make install" should install an
>    uninstaller (like this: "make -n uninstall > uninstaller; install
>    uninstaller").

This would indeed be useful.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "David" == David Masterson <dmaster@synopsys.com> writes:

    David> 2. To allow for source removal, "make install" should
    David> install an uninstaller (like this: "make -n uninstall >
    David> uninstaller; install uninstaller").

Which  GNU software doesn't  allow you  to "rm  -rf" the  whole source
directory after the  "make install"?  I mean, which  will not function
after this?



-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[David Masterson]

>>>>> Lee Sau Dan writes:

>>>>> "David" == David Masterson <dmaster@synopsys.com> writes:

David> 2. To allow for source removal, "make install" should install
David> an uninstaller (like this: "make -n uninstall > uninstaller;
David> install uninstaller").

> Which GNU software doesn't allow you to "rm -rf" the whole source
> directory after the "make install"?  I mean, which will not function
> after this?

Sorry, the statement I made is a bit hard to interpret.  What I meant
is that, if you remove the source (to save space or whatever), then
you cannot run "make uninstall".  Therefore, if you want to have the
capability to do a "make uninstall" after removing the source, then
"make install" needs to install an uninstaller (particularly if the
program is installed in a common area like /usr/local).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "David" == David Masterson <dmaster@synopsys.com> writes:

    David> GNU tools generally are not distributed with any package
    David> manager in mind.  They have "make install" and some have
    David> "make uninstall" as the replacement for a package manager.
    David> MS-Windows actually has this issue well handled.  

Most      GNU      softwares      nowadays      have      "./configure
--prefix=/anywhere/you/like/foobar"  so that  the "make  install" will
only   put   files   there.     Uninstalling   is   simply   "rm   -rf
/anywhere/you/like/foobar".



-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[David Masterson]

>>>>> Lee Sau Dan writes:

>>>>> "David" == David Masterson <dmaster@synopsys.com> writes:
David> GNU tools generally are not distributed with any package
David> manager in mind.  They have "make install" and some have
David> "make uninstall" as the replacement for a package manager.
David> MS-Windows actually has this issue well handled.  

> Most GNU softwares nowadays have "./configure
> --prefix=/anywhere/you/like/foobar" so that the "make install" will
> only put files there.  Uninstalling is simply "rm -rf
> /anywhere/you/like/foobar".

This does not work if "/anywhere/you/like/foobar" (for all "foobar")
is "/usr/local" as is most often the case.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Luis Fernandes]

>>>>> "dmaster" == David Masterson <dmaster@synopsys.com> writes:

>>>>> Lee Sau Dan writes:
>>>>> "David" == David Masterson <dmaster@synopsys.com> writes:
    David> GNU tools generally are not distributed with any package
    David> manager in mind.  They have "make install" and some have
    David> "make uninstall" as the replacement for a package manager.
    David> MS-Windows actually has this issue well handled.

    >> Most GNU softwares nowadays have "./configure
    >> --prefix=/anywhere/you/like/foobar" so that the "make install"
    >> will only put files there.  Uninstalling is simply "rm -rf
    >> /anywhere/you/like/foobar".

    dmaster> This does not work if "/anywhere/you/like/foobar" (for
    dmaster> all "foobar") is "/usr/local" as is most often the case.

Exactly! I NEVER use the default configure for Emacs because it puts
things "all over the place".

I change it so *everything* gets installed in one place;
e.g. /usr/local/emacs-21.1/. 

This also allows me to run 2 different versions in parallel by just
changing the link in /usr/local/bin/emacs to
/usr/local/emacs-21.1/bin/emacs or whatever other version.

Basically, /usr/local/bin is just a collection of symbolic links to
packages in /usr/local/packageXXX-version/bin/.

Old version are easily deleted by just nuking
/usr/local/packageXXX-version and changing links in /usr/local/bin.

Let's start the ball rolling with the Emacs configure, please.

Re: Software/HD ecology

[David Masterson]

>>>>> Luis Fernandes writes:
>>>>> "dmaster" == David Masterson <dmaster@synopsys.com> writes:
>>>>> Lee Sau Dan writes:
>>>>> "David" == David Masterson <dmaster@synopsys.com> writes:

David> GNU tools generally are not distributed with any package
David> manager in mind.  They have "make install" and some have
David> "make uninstall" as the replacement for a package manager.
David> MS-Windows actually has this issue well handled.

>>> Most GNU softwares nowadays have "./configure
>>> --prefix=/anywhere/you/like/foobar" so that the "make install"
>>> will only put files there.  Uninstalling is simply "rm -rf
>>> /anywhere/you/like/foobar".

dmaster> This does not work if "/anywhere/you/like/foobar" (for
dmaster> all "foobar") is "/usr/local" as is most often the case.

> Exactly! I NEVER use the default configure for Emacs because it puts
> things "all over the place".

I know that you can do this and that's where tools like Stow and
Pkglink come in.  However, most people find a simple "configure; make;
make install" is good enough for them *UNTIL* they get to the point of
wanting to uninstall (think ahead? who me?).  Having "make install"
install an "uninstaller" would take care of this and it's really not
that difficult to implement:

        install: $(TARGETS)
                for x in $(TARGETS); do \
                        echo $(RM) $(TARGET_DIR)/$$x > uninstaller; \
                        install $$x $(TARGET_DIR); \
                done
                install uninstaller $(TARGET_DIR)

Give "uninstaller" some sort of unique name to taste...

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Luis Fernandes]

I agree with your proposal for an uninstgaller for all packages. 

What I am proposing is for all packages to be compartmentalized, by
default ("configure; make; make install"), in their own directories
with version numbers so multiple version of the same package can
co-exist without conflicts and collisions.

Re: Software/HD ecology

[Miles Bader]

Luis Fernandes <elf@ee.ryerson.ca> writes:
> What I am proposing is for all packages to be compartmentalized, by
> default ("configure; make; make install"), in their own directories
> with version numbers so multiple version of the same package can
> co-exist without conflicts and collisions.

I suspect that most of the time people don't really care about such
functionality, at least for the great majority of simple packages --
and many packages where multiple version support _is_ important
(e.g., emacs, gcc) already support it it.

People who have unusual requirements can just use stow or something.

-Miles
-- 
Would you like fries with that?

Re: Software/HD ecology

[Luis Fernandes]

>>>>> "miles" == Miles Bader <miles@lsi.nec.co.jp> writes:

    miles> of simple packages -- and many packages where multiple
    miles> version support _is_ important (e.g., emacs, gcc) already
    miles> support it it.

The support is there, but it is not enabled *by default*. I would
like to see *all* of emacs installed into a *single* directory.

To install emacs (in /usr/local/emacs-21.3/) I (Joe Average User)
would type: configure; make ; make install

I, or the script, can make a link from /usr/local/bin/emacs to
/usr/local/emacs-21.3/bin/emacs.

To un-install emacs, I would type: rm -rf /usr/local/emacs-21.3/
To clean-up, I would type: rm /usr/local/bin/emacs

Re: Software/HD ecology

[Rodney Sparapani]

I don't think anyone would want to
configure --prefix=/usr/local/emacs-21.3
If you do that, then you will have to either link everything (perhaps 
with stow)
to where it really belongs or change all of your environment variables like
PATH, MANPATH, etc.  The solution that fink uses is much better since it
creates a /sw directory so you only have to change your environment 
variables
once.

-- 
Rodney Sparapani              Medical College of Wisconsin
Sr. Biostatistician           Patient Care & Outcomes Research
rsparapa@mcw.edu              http://www.mcw.edu/pcor
Was 'Name That Tune' rigged?  WWLD -- What Would Lombardi Do

Re: Software/HD ecology

[Miles Bader]

Luis Fernandes <elf@ee.ryerson.ca> writes:
> The support is there, but it is not enabled *by default*. I would
> like to see *all* of emacs installed into a *single* directory.

Yes I know you would; but in order for GNU standards to change
(thus confusing and annoying everybody out there used to the current
standard), there has to be a better reason than `I think it's more tidy.'

One _possible_ reason is to make multi-version support easier, but as I
said, packages already do this within the confines of the current standard.

-Miles
-- 
Would you like fries with that?

Re: Software/HD ecology

[Luis Fernandes]

>>>>> "miles" == Miles Bader <miles@gnu.org> writes:

    miles> Yes I know you would; but in order for GNU standards to
    miles> change (thus confusing and annoying everybody out there
    miles> used to the current standard), there has to be a better
    miles> reason than `I think it's more tidy.'

Yes, I see your point.  And as Kai pointed out it's not really
perfect, there's post-install fiddling involved.

Anyway, I would like to see dmaster's idea of an "uninstall-emacs"
script created and installed in future distros of emacs.

Re: Software/HD ecology

[Kai Großjohann]

Luis Fernandes <elf@ee.ryerson.ca> writes:

> Anyway, I would like to see dmaster's idea of an "uninstall-emacs"
> script created and installed in future distros of emacs.

Seconded.

-- 
Ambibibentists unite!

Re: Software/HD ecology

[David Masterson]

>>>>> Miles Bader writes:

> One _possible_ reason is to make multi-version support easier, but
> as I said, packages already do this within the confines of the
> current standard.

The only thing that is really needed in the current standard is
"uninstall" *after* removal of the source directory.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[David Masterson]

>>>>> Luis Fernandes writes:

> What I am proposing is for all packages to be compartmentalized, by
> default ("configure; make; make install"), in their own directories
> with version numbers so multiple version of the same package can
> co-exist without conflicts and collisions.

The basic problem with this is that, unless you have a program like
Stow to create the symlink farm, it will require that you modify your
PATH(s) to include the packages that you install.  If you install
*many* packages this way, you could wind up with a *VERY* large PATH
that will break some shells (I know that csh has limitations on some
UNIXes).  Therefore, this shouldn't be the default -- it can be
handled by configure options (like setting "prefix").

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Luis Fernandes]

>>>>> "dmaster" == David Masterson <dmaster@synopsys.com> writes:

    dmaster> The basic problem with this is that, unless you have a
    dmaster> program like Stow to create the symlink farm, it will
    dmaster> require that you modify your PATH(s) to include the
    dmaster> packages that you install.

Only /usr/local/bin needs to be in the user's path. After installing
emacs, I manually make the links from /usr/local/bin to
/usr/local/emacs-21.1/bin.  "make install" can easily make the links
from /usr/local/bin to the actual package directory.

We use this installation policy successfully here. 

Another (unintentional) benefit of this policy is that packages can
be easily migrated to another system (of similar architecture) by
simplying tarring up a single directory and untarring it on the new
system. A colleague wanted my emacs "installation/customizations" on
his GNU/Linux system at home so he just tarred-up
/usr/local/emacs-21.1 ftp'd it home and untarred it, made the symlinks
in /usr/local/bin and was up and running.

Re: Software/HD ecology

[Kai Großjohann]

Luis Fernandes <elf@ee.ryerson.ca> writes:

> Only /usr/local/bin needs to be in the user's path. After installing
> emacs, I manually make the links from /usr/local/bin to
> /usr/local/emacs-21.1/bin.

You will need similar links for the man pages and for the info
files.  (And for info, there is the `dir' file to take care of.)

IMHO, a software isn't fully installed unless its documentation is
also easily accessible.
-- 
Ambibibentists unite!

Re: Software/HD ecology

[Peter S Galbraith]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:

> Luis Fernandes <elf@ee.ryerson.ca> writes:
> 
> > Only /usr/local/bin needs to be in the user's path. After installing
> > emacs, I manually make the links from /usr/local/bin to
> > /usr/local/emacs-21.1/bin.
> 
> You will need similar links for the man pages and for the info
> files.  (And for info, there is the `dir' file to take care of.)

Exactly what I was thinking.
 
> IMHO, a software isn't fully installed unless its documentation is
> also easily accessible.

And some software need editable configuration files, which should be
under /etc and be preserved on upgrades.  It's all starting to sound
like package management to me.

Re: Software/HD ecology

[Luis Fernandes]

    kai> You will need similar links for the man pages and for the
    kai> info files.  (And for info, there is the `dir' file to take
    kai> care of.)

My emacs installation is a shell script that does post-install
adjustments like man-pages, site-lisp, etc. The only change I make to
the script for each new installation, is the emacs version number.

The man-pages get installed in /usr/local/man/manl.
Site-customizations get installed in /usr/common/emacs/site-lisp (the
/usr/common filesystem is mounted on all hosts and is architecture
neutral) and is sym-linked into the /usr/local/emacs-21.1 tree by the
post-install script.

    kai> IMHO, a software isn't fully installed unless its
    kai> documentation is also easily accessible.

Nobody (mostly) reads documentation here; it's faster and easier to
ask me.

Re: Software/HD ecology

[David Masterson]

>>>>> Luis Fernandes writes:
>>>>> "dmaster" == David Masterson <dmaster@synopsys.com> writes:

dmaster> The basic problem with this is that, unless you have a
dmaster> program like Stow to create the symlink farm, it will require
dmaster> that you modify your PATH(s) to include the packages that you
dmaster> install.

> Only /usr/local/bin needs to be in the user's path. After installing
> emacs, I manually make the links from /usr/local/bin to
> /usr/local/emacs-21.1/bin.  "make install" can easily make the links
> from /usr/local/bin to the actual package directory.

We're saying the same thing.  In your case, you manually make the
links.  In my case, I'd use Stow or Pkglink to create the links.  You
wouldn't want "make install" to do the links because it could wind up
overwriting the links from a previous install of the package.
Sometimes you want that, but sometimes you don't -- best to let a
separate program (like Stow) help you uninstall the old version and
install the new version into /usr/local.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Lee Sau Dan]

>>>>> "Ajanta" == Ajanta  <ajanta@no.spam> writes:

    >> To uninstall the application, simply "rm -rf /usr/local/foobar"
    >> and you're done!

    Ajanta> Here is the example a poster gave from his system. There
    Ajanta> may or may not be other emacs related named files there,
    Ajanta> these are just the matches on the *name* emacs:

    Ajanta>    % find /usr -name emacs -print 
    Ajanta> /usr/bin/emacs
    Ajanta> /usr/info/emacs
    Ajanta> /usr/libexec/emacs
    Ajanta> /usr/local/bin/emacs
    Ajanta> /usr/share/emacs
    Ajanta> /usr/share/info/emacs

    Ajanta> To duplicate the convenience implied in your suggestion,
    Ajanta> one would have to delete /usr.

Bad practise.   This is by no means  imposed on the user  by Emacs.  A
simple  "./configure  --prefix=/my/installed/apps/emacs"  followed  by
"make" and then "su -" and make install" would do the things properly.



    Ajanta> What is needed:

    Ajanta> (1) To change the culture, so that every program comes
    Ajanta> with a safe and complete uninstall option.

Most unix programs are already exhibiting this behaviour.


    Ajanta> (2) To empower the user, so he/she can easily discover
    Ajanta> what a particular file on his/her computer is for, and
    Ajanta> where are all the files related to the package xyz. 

        rpm -qf /etc/someprogrc 
would reveal it, for instance.


    Ajanta> I haven't come across many programs with long descriptive
    Ajanta> file names.  However, I'll avoid this direction because I
    Ajanta> view it as less relevant.  I want precise and reliable
    Ajanta> tools to know what a file was for. I don't want to guess
    Ajanta> such things from names.

Most Linux distros  have a package management tool  that does what you
want.  Only the minimalistic ones (e.g. the single-floppy flavours) do
not.


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Software/HD ecology

[Alfred M. Szmidt]

       Ajanta> (1) To change the culture, so that every program comes
       Ajanta> with a safe and complete uninstall option.

   Most unix programs are already exhibiting this behaviour.

I can not think of any Unix program that exhibites this behaviour.  I
can think of several GNU programs that do.  And ever more programs
that use autoconf/automake.

   Most Linux distros  have a package management tool  that does what you
   want.  Only the minimalistic ones (e.g. the single-floppy flavours) do
   not.

No version of Linux has a package manager.  It is a kernel, it cannot
have a package manager.  What you mean is a variant of GNU using Linux
as its kernel.  See http://www.gnu.org/gnu/linux-and-gnu.html

Re: Software/HD ecology

[Peter S Galbraith]

Alfred M. Szmidt <ams@kemisten.nu> wrote:

>    Most Linux distros  have a package management tool  that does what you
>    want.  Only the minimalistic ones (e.g. the single-floppy flavours) do
>    not.
> 
> No version of Linux has a package manager.  It is a kernel, it cannot
> have a package manager.  What you mean is a variant of GNU using Linux
> as its kernel.  See http://www.gnu.org/gnu/linux-and-gnu.html

Oh please.  He said Linux _distros_.  Man...

Yes, most Linux distros  have a package management tool.

Re: Software/HD ecology

[Alfred M. Szmidt]

   Oh please.  He said Linux _distros_.  Man...

Yes, distributions of the Linux kernel.  I don't think I have seen a
kernel with a package manager.

   Yes, most Linux distros  have a package management tool.

No, no Linux distribution has a package managment tool.  Linux is a
kernel.

Re: Software/HD ecology

[Peter S Galbraith]

Alfred M. Szmidt <ams@kemisten.nu> wrote:

>    Oh please.  He said Linux _distros_.  Man...
> 
> Yes, distributions of the Linux kernel.  I don't think I have seen a
> kernel with a package manager.
> 
>    Yes, most Linux distros  have a package management tool.
> 
> No, no Linux distribution has a package managment tool.  Linux is a
> kernel.

Get off it.  Linux is a kernel.  Linux distributions are a kernel plus
all the other stuff.  There are no Linux distributions of only a kernel.
Yes, he could have said GNU/Linux distros, but the context made it
abundantly clear that he wasn't talking about just a kernel.

Re: Software/HD ecology

[Alfred M. Szmidt]

   Get off it.  Linux is a kernel.  Linux distributions are a kernel plus
   all the other stuff.  There are no Linux distributions of only a kernel.

And this "other stuff" is a variant of GNU.

   Yes, he could have said GNU/Linux distros, but the context made it
   abundantly clear that he wasn't talking about just a kernel.

It was also wrong.  Is there any reason why you need to start flaming?

Re: Software/HD ecology

[David Kastrup]

"Alfred M. Szmidt" <ams@kemisten.nu> writes:

[Peter Galbraith:]
>    Get off it.  Linux is a kernel.  Linux distributions are a kernel plus
>    all the other stuff.  There are no Linux distributions of only a kernel.
> 
> And this "other stuff" is a variant of GNU.
> 
>    Yes, he could have said GNU/Linux distros, but the context made it
>    abundantly clear that he wasn't talking about just a kernel.
> 
> It was also wrong.  Is there any reason why you need to start flaming?

Playing stupid might make you feel smug, but is hardly productive in
winning people to your cause.  And I don't see that Peter was flaming
here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Software/HD ecology

[Alfred M. Szmidt]

   Playing stupid might make you feel smug, but is hardly productive in
   winning people to your cause.  And I don't see that Peter was flaming
   here.

It was an polite correction, Peter obviously did not like it and
posted an reply that had an intent to provoke someone.  Calling
someone stupid is clearly an intent for a flame...

Re: Software/HD ecology

[Peter S Galbraith]

Alfred M. Szmidt <ams@kemisten.nu> wrote:

>    Get off it.  Linux is a kernel.  Linux distributions are a kernel plus
>    all the other stuff.  There are no Linux distributions of only a kernel.
> 
> And this "other stuff" is a variant of GNU.
> 
>    Yes, he could have said GNU/Linux distros, but the context made it
>    abundantly clear that he wasn't talking about just a kernel.
> 
> It was also wrong.  Is there any reason why you need to start flaming?

Because you are being _very_ pedantic and not addressing the question.
I don't need to be lectured about GNU.  You're preaching to the choir on
this list.

Re: Software/HD ecology

[Alfred M. Szmidt]

   You're preaching to the choir on this list.

If I was "preaching" to the "choir" then I wouldn't have needed to
state this fact.

Re: Software/HD ecology

[David Kastrup]

"Alfred M. Szmidt" <ams@kemisten.nu> writes:

>    You're preaching to the choir on this list.
> 
> If I was "preaching" to the "choir" then I wouldn't have needed to
> state this fact.

You didn't need to, particularly not in as asinine a manner.  What
makes you think you are responsible for lecturing the rest of this
list about GNU?  Where does your need to play stupid in order to drive
home a point of pedantry arise?  If you suffer from attacks of such
compulsive behavior more often, perhaps you should try to get a
professional opinion.

Sure, RMS can be obsessive about this issue as well, but in contrast
to you he does not play silly games around the issue.  If you really
insist to be annoying, take a hint from him, and be straightforward
about it.  If you feel a need to smug around, chances are that the
matter is not important to you except for showing off.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Software/HD ecology

[Peter S Galbraith]

Ajanta <ajanta@no.spam> wrote:

> > Anyway, nowadays,  people almost always use package  managers, such as
> > RPM in RedHat and SuSE.
> 
> To have package managers which work on only one or two sub-flavors or,
> as in Fink's case, only on the software downloaded from one source is
> really not such a hot solution (though a welcome "patch").

?

Package managers are a working solution now.  There's no way you'll get
the thousands of software titles out there to change to solve your
problem, since it's not a problem for most of them.

Use a package management system too and you'll solve your problem!

To address specific points:

> To have package managers which work on only one or two sub-flavors

Sub-flavors of what?  Unix?  Well these tools are free, so adapt them to
your flavor.  Obviously the one or two sub-flavors have solved their
problem (It's much more than one or two.  Just about every GNU/Linux
distrubition has some sort of package management system).

> only on the software downloaded from one source

RPMs often come from different sources (I don't view that as a plus),
and Debian packages just about everything!

Peter

Re: Software/HD ecology

[Peter S Galbraith]

Ajanta <ajanta@no.spam> wrote:

> Lee Sau Dan <danlee@informatik.uni-freiburg.de> wrote:
> 
> > 'man rpm', if you're on a RedHat or SuSE system.
> 
> As you could perhaps guess from the Newsgroups line, the specific
> systems we were discussing are Mac OS X and BSD's. Or we could discuss
> all Unix-like systems in general. They don't have "rpm". From your
> statement, it would seem it is not even a Linux syandard, just
> something that comes with two packages?

Doesn't mean one needs to reinvent it.  It's free software.

But I've said this before, and others think that something simple will
be better than the status-quo.

Re: Software/HD ecology

[Ajanta]

Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:

> At our site, we have a directory for software with subdirs for each
> program, and subsubdirs for each version.  For example, 
> 
>     ./configure --prefix=/usr/sw/emacs/21.2
> 
> is sufficient to configure Emacs in such a way that subsequent `make'
> and `make install' can be undone easily by just removing the
> directory /usr/sw/emacs/21.2.  This works because Emacs is the only
> program in that directory.
> 
> It's a very simple approach, but it works well enough for us.

I am a beginner at this, so let me understand step-by-step. If you
./configure with the above option, make, make install, will everything
remain in /usr/sw/emacs/21.2? Where do the binaries go? 

If it is /uar/sw/bin, I can imagine you can just put it in your path.
However, if it is /usr/sw/emacs/21.2/bin, then do you have to modify
the path each time you install a program? (I don't see either as a big
deal, I am just trying to figure out what actually happens.)

Thanks.

A

Re: Software/HD ecology

[David Masterson]

>>>>> Ajanta  writes:

> Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:

>> At our site, we have a directory for software with subdirs for each
>> program, and subsubdirs for each version.  For example, 
>> 
>> ./configure --prefix=/usr/sw/emacs/21.2
>> 
>> is sufficient to configure Emacs in such a way that subsequent `make'
>> and `make install' can be undone easily by just removing the
>> directory /usr/sw/emacs/21.2.  This works because Emacs is the only
>> program in that directory.
>> 
>> It's a very simple approach, but it works well enough for us.

> I am a beginner at this, so let me understand step-by-step. If you
> ./configure with the above option, make, make install, will
> everything remain in /usr/sw/emacs/21.2? Where do the binaries go?

A directory structure is created under /usr/sw/emacs/21.2 with a
standard layout for all the different parts (like 'bin' for binaries
and 'lib' for libraries).

> If it is /uar/sw/bin, I can imagine you can just put it in your
> path.  However, if it is /usr/sw/emacs/21.2/bin, then do you have to
> modify the path each time you install a program? (I don't see either
> as a big deal, I am just trying to figure out what actually
> happens.)

This is potentially true if you use _just_ this scheme.  In fact, if
you carry this to extremes such that each program is installed in it's
own directory structure, your PATH could become quite long.  However,
tools like GNU Stow build on this scheme by adding the ability to
symlink these directories (and subfiles) into the standard location
(typically /usr/local) so that your PATH need only have the typical
/usr/local/bin in it.  The tools like Stow can also move the symlinks
to a new version of the package or remove the symlinks altogether.  In
this way, by removing the symlinks and then removing the package's
personal directory, you are sure that all of that version of the
package has been removed.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> If it is /uar/sw/bin, I can imagine you can just put it in your path.
> However, if it is /usr/sw/emacs/21.2/bin, then do you have to modify
> the path each time you install a program? (I don't see either as a big
> deal, I am just trying to figure out what actually happens.)

I forgot one detail: after installing Emacs into /usr/sw/emacs/21.1,
we create a file /usr/sw/emacs/21.1/.bashenv which contains commands
to frob $PATH and $MANPATH and so on.

Then people put

    . /usr/sw/emacs/21.1/.bashenv

into their ~/.bash_profile.

Additionally, one version of each program is declared the default
version.  So there would be a symlink /usr/sw/emacs/default pointing
to /usr/sw/emacs/21.1.  Then people can put the following into their
.bash_profile to get the default version of all the programs:

    for f in /usr/sw/*/default/.bashenv; do
        . $f
    done

Yes, this means that $PATH and $MANPATH grow quite long.  But this
only becomes a problem when you have lots of packages in /usr/sw.  We
do not have that many of them, so this scheme is still workable for
us.

We used to have a home-grown shell script which created a directory
/usr/sw/bin and populated it with symlinks to programs in
/usr/sw/*/default/bin.  (And similar for /usr/sw/man and
/usr/sw/info.)  In the long run, we might wish to migrate to GNU Stow
or a similar tool.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Stefan Monnier <foo@acm.com>]

>> > Why is that comparable with the clutter of tens of MB and 100's of files
>> > scattered around?
>> Could you expand on your "scattered around" ?
> I didn't keep a tally but here is an example. I recently I obtained a
> beta distribution (not emacs) which didn't work out (fair enough,
> that's a known risk in beta) and I deleted it. Or so I thought. I still
> keep running into some files from it. What gives me pause is that these

Do you have anything concrete like filenames so we might be able
to do something about it or at least explain why things are the
way they are ?

> As I mentioned in the beginning post of this thread, the distribution
> of Emacs 21.3.50 that I got for Mac OSX has *three* executables of

All under the single `Emacs.app' directory.  Seems clean enough to me.


        Stefan


PS: I'm not quite sure what you want w.r.t the non-english language support.
Do you also consider it as clutter ?  If so how and why ?

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Ajanta]

Stefan Monnier <foo@acm.com> wrote:

> Do you have anything concrete like filenames so we might be able
> to do something about it or at least explain why things are the
> way they are ?

Obviously, I have failed to express myself. As you said, emacs has
close to 3,000 files. If I install ten similarly large packages, that
is 30,000 files. I don't want to get to know them personally. What I
want is to be able to install and uninstall such packages cleanly and
safely.

> > As I mentioned in the beginning post of this thread, the distribution
> > of Emacs 21.3.50 that I got for Mac OSX has *three* executables of
> 
> All under the single `Emacs.app' directory.  Seems clean enough to me.

I mentioned that as a different kind of bug: 3 files where 1 is needed,
16 MB of wasted space.
 
> PS: I'm not quite sure what you want w.r.t the non-english language support.
> Do you also consider it as clutter?  If so how and why ?

At present the languages number in 10's but soon it may be 100's. I am
glad they are included. It is not clutter in the *distribution*, but it
becomes clutter in my *system* if I am stuck with it all with no tools
to safely select *my* language(s). 

An analogy might be to ship a fat distribution with binaries for every
cpu architecture and OS, and expect a user to keep everything because
it is a lot of work to separate them. That would be stupid. IMHO it
would be equally stupid to force people to keep 100's of languages they
have no prayer of learning/understanding/needing in one lifetime.

A

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Stefan Monnier <foo@acm.com>]

I fail like I can't have a rational argument because you keep shifting
the focus from one issue to another.  For example you say:
 
> Obviously, I have failed to express myself. As you said, emacs has
> close to 3,000 files. If I install ten similarly large packages, that
> is 30,000 files. I don't want to get to know them personally. What I
> want is to be able to install and uninstall such packages cleanly and
> safely.

Which I addressed with:

>> All under the single `Emacs.app' directory.  Seems clean enough to me.

But then you replied by shifting to yet-another point:

> I mentioned that as a different kind of bug: 3 files where 1 is needed,
> 16 MB of wasted space.

As for:

> At present the languages number in 10's but soon it may be 100's. I am
> glad they are included. It is not clutter in the *distribution*, but it
> becomes clutter in my *system* if I am stuck with it all with no tools
> to safely select *my* language(s).

What's clutterish about them ?  Have you bothered to take a look
at the lisp/languages directory I mentioned earlier ?

Why does this support for other languages bother you, whereas support
for TPU-emulation, RMail, Simula, etc... doesn't ?  Do you intend to learn
Simula ?

> An analogy might be to ship a fat distribution with binaries for every
> cpu architecture and OS, and expect a user to keep everything because
> it is a lot of work to separate them. That would be stupid. IMHO it
> would be equally stupid to force people to keep 100's of languages they
> have no prayer of learning/understanding/needing in one lifetime.

I can see it as waste, but I still completely fail to see what's clutterish
about it.  The only thing I understand is that you have no clue where
to find what in all those files.  Whether that's bad or not depends on how
much effort you've put into it.


        Stefan

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Anil Trivedi]

Stefan Monnier <foo@acm.com> wrote:

> I fail like I can't have a rational argument because you keep shifting
> the focus from one issue to another. 

But several issues *have* been raised here: (1) Don't waste disk space,
(2) Enable users to safely delete either the functionality or files
they know they don't need, (3) And include a complete uninstall script.

Clutter is less of a problem if a complete uninstall option is there,
but it is a major problem if users have to rely on their own wits to
locate and delete the files.

> >> All under the single `Emacs.app' directory.  Seems clean enough to me.

Stefan, looks like we have both been working all night and need a very,
very strong cup of coffee. :-) Rubbing my eyes, this is what I see on
my system:

   anil% find /usr -name emacs -print
   /usr/bin/emacs
   /usr/info/emacs
   /usr/libexec/emacs
   /usr/local/bin/emacs
   /usr/share/emacs
   /usr/share/info/emacs

I only searched for the *name* emacs, there may or may not be other
emacs-ralated files and directories with different names. I love emacs
but if someone didn't want to keep it, should they just delete /usr?!

> Why does this support for other languages bother you, whereas 
> support for TPU-emulation, RMail, Simula, etc... doesn't?  Do you intend 
> to learn Simula?

When you don't need such things and they are taking more than minimal
disk space, you should be abe to delete them too. 

However, human languages are fundamentally different. There is zero
chance that every major program will include a newsreader or TPU or
Simula. It is a near 100% certainty that every major program will
increasingly come with support for a large number of human languages.
If I accumulate 100 programs and there are 100 supported langaues I
don't understand, that would be 10,000 instances of language support I
don't need and can't use. I don't expect to have that kind of problem
with Gnus, Rmail, or Simula.

Anil Trivedi

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Miles Bader]

Anil Trivedi <anil@null.invalid> writes:
> But several issues *have* been raised here: (1) Don't waste disk space,
> (2) Enable users to safely delete either the functionality or files
> they know they don't need, (3) And include a complete uninstall script.

All these have been addressed in this thread (but it is true that the
people asking these questions keep squirming around and changing the
topic):
 
 (1) The added complexity necessary to actually do this manner is in
     most cases far more harmful than the wasted disk space (certainly
     emacs is pretty small compared to modern hard disks!).

     There _are_ certain parts of emacs which come in large monolithic
     easy-to-delete chunks (e.g., LEIM), which might be worth providing
     a `delete' option for, but I think they can dealt with on a
     case-by-case basis.

 (2) This is a very vague request (and whenever this issue has been
     raised elsewhere in this thread, the language used has been
     similarly vague).

     Allowing users to `safely and easily' delete _files_ is hard, given
     emacs' structure and history (if emacs had been designed from the
     start with this in mind, of course it would easier), and of little
     obvious benefit.

     Allowing users to delete _functionality_ is similarly hard, but
     probably more beneficial, in specific cases -- feel free to suggest
     places where you feel this should be done, and how the
     user-interface for this would work.

 (3) Emacs already has an uninstall function

> this is what I see on my system:
> 
>    anil% find /usr -name emacs -print
>    /usr/bin/emacs
>    /usr/info/emacs
>    /usr/libexec/emacs
>    /usr/local/bin/emacs
>    /usr/share/emacs
>    /usr/share/info/emacs

Um, that's how unix(-like) systems work.  Emacs did not decide this
layout, it merely follows it.  Feel free to complain, but it isn't
going to change anytime soon.

> > Why does this support for other languages bother you, whereas 
> > support for TPU-emulation, RMail, Simula, etc... doesn't?  Do you intend 
> > to learn Simula?
> 
> When you don't need such things and they are taking more than minimal
> disk space, you should be abe to delete them too. 

See points (1) and (2).

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Software/HD ecology

[Kai Großjohann]

[ removed comp.text.tex from Newsgroups ]

Anil Trivedi <anil@null.invalid> writes:

> Stefan, looks like we have both been working all night and need a very,
> very strong cup of coffee. :-) Rubbing my eyes, this is what I see on
> my system:
>
>    anil% find /usr -name emacs -print
>    /usr/bin/emacs
>    /usr/info/emacs
>    /usr/libexec/emacs
>    /usr/local/bin/emacs
>    /usr/share/emacs
>    /usr/share/info/emacs

I gather that you didn't install Emacs there.  Then please go to the
person (or organization) who did it and ask them how to delete Emacs.

(On my (Debian) system, there are similar files and directories and
"dpkg --purge emacs" will delete them.)

If you had installed Emacs there from the source, and if you had kept
the source directory around, then you could have gone to the source
directory and then typed `make uninstall' and the above files would
have been deleted.

The previous paragraph might be useful for said people (or
organizations) who installed Emacs into those directories onto your
system, to produce a way for you to delete Emacs.

There is a problem here: I just told you some messages back that you
can delete the source directory, now I'm telling you you need to keep
it for `make uninstall'.  Solution: after installing Emacs, type
`make -n uninstall' and save the result somewhere safe.  The result
contains all the commands necessary to uninstall Emacs.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[David Masterson]

>>>>> Miles Bader writes:

>      There _are_ certain parts of emacs which come in large
>      monolithic easy-to-delete chunks (e.g., LEIM), which might be
>      worth providing a `delete' option for, but I think they can
>      dealt with on a case-by-case basis.

Ummm.  Vagueness...?

What you've described above is the need for "Emacs packages".  That
is, if LEIM was a "package" and Emacs had a package management system,
then deleting the package is trivial.  There are two parts to that:

1. Breaking up Emacs into well-defined packages.
2. Developing an Emacs package system.

XEmacs has largely done this, but I'm not sure of the flexibility of
their package management system (I don't think it handles packages
that have separate executables, for instance).

Oh, BTW, how does "make uninstall" work if you delete (or never had!)
the build directory?  Perhaps there should be a "uninstall-script"
that is created *and* installed by "make install"?

>> this is what I see on my system:
>> 
>> anil% find /usr -name emacs -print
>> /usr/bin/emacs
>> /usr/info/emacs
>> /usr/libexec/emacs
>> /usr/local/bin/emacs
>> /usr/share/emacs
>> /usr/share/info/emacs

> Um, that's how unix(-like) systems work.  Emacs did not decide this
> layout, it merely follows it.  Feel free to complain, but it isn't
> going to change anytime soon.

It's apparent by the above that, in essense, multiple installations of
Emacs were done on the system (even if they are just symlinked
together).  Anil's point is, if he wanted to remove one of those
installations, could it he do it safely?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Stefan Monnier <foo@acm.com>]

> Oh, BTW, how does "make uninstall" work if you delete (or never had!)
> the build directory?  Perhaps there should be a "uninstall-script"
> that is created *and* installed by "make install"?

Can you move this to some unix newsgroup ?
It has nothing to do with Emacs, really.


        Stefan

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[David Masterson]

>>>>> "Stefan Monnier writes:

>> Oh, BTW, how does "make uninstall" work if you delete (or never had!)
>> the build directory?  Perhaps there should be a "uninstall-script"
>> that is created *and* installed by "make install"?

> Can you move this to some unix newsgroup ?
> It has nothing to do with Emacs, really.

Not completely true, but I won't go into further.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Galen Boyer]

On Thu, 12 Dec 2002, ajanta@no.spam wrote:

> Obviously, I have failed to express myself. As you said, emacs
> has close to 3,000 files. If I install ten similarly large
> packages, that is 30,000 files. I don't want to get to know
> them personally. What I want is to be able to install and
> uninstall such packages cleanly and safely.

Why can't you just remove the entire directory structure?  The
files aren't scattered everywhere.  Install into its own
directory structure and you know where all the files are.
-- 
Galen Boyer

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Anil Trivedi]

> At present the languages number in 10's but soon it may be 100's. I am
> glad they are included. It is not clutter in the *distribution*, but it
> becomes clutter in my *system* if I am stuck with it all with no tools
> to safely select *my* language(s). 
> 
> An analogy might be to ship a fat distribution with binaries for every
> cpu architecture and OS, and expect a user to keep everything because
> it is a lot of work to separate them. That would be stupid. IMHO it
> would be equally stupid to force people to keep 100's of languages they
> have no prayer of learning/understanding/needing in one lifetime.

I just wrote this elsewhere in another context (file attributes) but
once more will do no harm: 

Unix was conceptualized for small systems and programs, where a user
might know every file, and actually need it. Indeed, he either wrote it
himself or copied from a friend he knew, and it was all in one
language, whatever it happened to be. 

Now we have hundreds of thousands of files, know nothing about them,
and routinely install packages that bring thousands of files and
support more languages than the United Nations! All well and good, but
as the system grows, the culture and the tools need to keep up too.

Anil Trivedi

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Miles Bader]

Anil Trivedi <anil@null.invalid> writes:
> Unix was conceptualized for small systems and programs, where a user
> might know every file, and actually need it. Indeed, he either wrote it
> himself or copied from a friend he knew, and it was all in one
> language, whatever it happened to be. 
> 
> Now we have hundreds of thousands of files, know nothing about them,
> and routinely install packages that bring thousands of files and
> support more languages than the United Nations! All well and good, but
> as the system grows, the culture and the tools need to keep up too.

Feel free to plan the revolution, but this has little to do with emacs...

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Software/HD ecology

[Kai Großjohann]

Ajanta <ajanta@no.spam> writes:

> Actually I don't understand this equivalence. Makefiles routinely come
> with targets like "clean" which presumably deletes files like .log/.o
> and of course "install".  If they could have a few extra targets, like
> "superclean" or "EnglishOnly", that's a few extra lines. Why is that
> comparable with the clutter of tens of MB and 100's of files scattered
> around?

Writing these few extra lines is a LOT of work.

Most important of all, it's not clear what to delete.  There would be
*endless* arguments about which files to remove and which files to
keep.  Emacs consists of 2297 files (on my system), it's very
difficult to untangle dependencies on them.

Let me give a simple example: some Linux distributions normally
install the *.elc files only and put the *.el files into an extra
package (*.rpm in the case of SuSE and Redhat), because the *.el files
are not needed for running Emacs.  (*.el files contain the source
code, and *.elc files are something like `object code' that's created
by `compiling' the *.el files.)

Then the ask how to send mail, and I tell them to type M-x
finder-commentary RET smtpmail RET.  This command prints some
documentation which is extracted from the beginning of the file
smtpmail.el.

But they don't have that file installed!

So, even the simple idea of `people don't want to look at the source
code, people just want to run the resulting binary' has failed!

(In an ideal world, there would be additional documentation for
smtpmail, outside the .el file.  But the world is not perfect, and
the documentation you get with M-x finder-commentary RET smtpmail RET
is quite adequate for setting it up, so nobody has ever bothered to
do anything about it.)

That said, XEmacs has the so-called package system which is a very
nifty thing indeed.  You install a base package of XEmacs which can
do almost nothing at all, and then you start installing XEmacs
packages which contain the Lisp code for various things.  It's very
easy this way to upgrade the packages that you have installed.

But then, a lot of XEmacs users install the Sumo tarball I think
which just contains all available packages :-)  (Caveat: I'm not an
XEmacs user, so what do I know what `a lot of XEmacs users' do!)
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Anil Trivedi]

Stefan Monnier wrote:

> As maintainers, it's in our own interest to keep things uncluttered,
> so we strive to find some logic to things such that we can organize our
> files and keep files in their logical place...I don't claim that the current
> arrangement is perfect, but it takes time and energy to think about how 
> to make it better and to fix the various places where things aren't 
> consistent and logical, so help is most welcome.

Kai Großjohann wrote:

> Writing these few extra lines is a LOT of work. Most important of all, it's 
> not clear what to delete.  There would be *endless* arguments about which 
> files to remove and which files to keep.  Emacs consists of 2297 files (on 
> my system), it's very difficult to untangle dependencies on them.

I would like to offer a few general suggestions for any large program,
not just emacs.

First of all, you should have a clear idea as to which files are needed
to complie the program but not to run it later, and which ones will be
needed forever to run the program. It is a sorry state of affairs if
the creators and maintainers themselves don't know the "dpendencies";
that indicates serious future troubles and the sooner one starts
correcting the situation the better.

1. You need "clean" and "distclean" to recover from failed compile
attempts. I think most programs do have this. (Personally, I might just
re-open the .tar file and start over.)

2. Once the program compiles, and works fine, the user should be able
to delete all files that were needed in compiling but will not be
needed in running it, or in uninstalling it.

3. Finally, should the user decide that this is not his kind of progam,
there should be an uninstall option that does safely and cleanly remove
everything. He should not have to go around checking in various bin,
share, libexec, man, lib, doc directories, etc., and guessing just
which files might belong to the program he wants to delete.

This seeme to be a minimum framework for responsible software
distribution.

4. As for languages, this is an early stage in globalization and the
"bloat" is perhaps manageable, but in a few years we may see support
for hundreds of languages and dozens of scripts. We would need to
enable a user to select what he needs and skip the rest.

Anil Trivedi

Re: Software/HD ecology

[Miles Bader]

Anil Trivedi <anil@null.invalid> writes:
> 1. You need "clean" and "distclean"
> 2. Once the program compiles, and works fine, the user should be able
>    to delete all files that were needed in compiling but will not be
>    needed in running it, or in uninstalling it.
> 3. Finally, should the user decide that this is not his kind of progam,
>    there should be an uninstall option
> This seeme to be a minimum framework for responsible software
> distribution.

Well, at least this is less vague that what you said before, but since
emacs already does all these things*, what's your complaint?

Do you want to report a bug with one of the make targets?

-Miles

* You need to do `make install' before (2), but that's alright
-- 
Fast, small, soon; pick any 2.

Re: Software/HD ecology

[Eli Zaretskii]

On Thu, 12 Dec 2002, Anil Trivedi wrote:

> I would like to offer a few general suggestions for any large program,
> not just emacs.

Like Miles pointed out, these suggestions are already implemented in 
Emacs (and are, in fact, part of GNU coding standards, so should be in 
any GNU software package).

> First of all, you should have a clear idea as to which files are needed
> to complie the program but not to run it later, and which ones will be
> needed forever to run the program.

Done.

> 1. You need "clean" and "distclean" to recover from failed compile
> attempts.

Emacs has these.

> 2. Once the program compiles, and works fine, the user should be able
> to delete all files that were needed in compiling but will not be
> needed in running it, or in uninstalling it.

Done.  You say "make install", and after that you can delete the entire 
source tree where you built Emacs.  All files that are needed to run 
Emacs are copied by "make install" into the installation directories.

> 3. Finally, should the user decide that this is not his kind of progam,
> there should be an uninstall option that does safely and cleanly remove
> everything.

That'd be "make uninstall".

Re: Software/HD ecology

[Phillip Lord]

>>>>> "Anil" == Anil Trivedi <anil@null.invalid> writes:

  Anil> Stefan Monnier wrote:

  >> As maintainers, it's in our own interest to keep things
  >> uncluttered, so we strive to find some logic to things such that
  >> we can organize our files and keep files in their logical
  >> place...I don't claim that the current arrangement is perfect,
  >> but it takes time and energy to think about how to make it better
  >> and to fix the various places where things aren't consistent and
  >> logical, so help is most welcome.

  Anil> Kai Gro_johann wrote:

  >> Writing these few extra lines is a LOT of work. Most important of
  >> all, it's not clear what to delete.  There would be *endless*
  >> arguments about which files to remove and which files to keep.
  >> Emacs consists of 2297 files (on my system), it's very difficult
  >> to untangle dependencies on them.

  Anil> 2. Once the program compiles, and works fine, the user should
  Anil>    be able
  Anil> to delete all files that were needed in compiling but will not
  Anil> be needed in running it, or in uninstalling it.

 
I think Kai's example showed the problem with this. 

Personally I find an emacs without the .el files half baked. The
reason for this is that I read the .el source as a form of
documentation. Clearly this makes me a specialist user, but none the
less a user. Similarly the hyper links in command documentation will
not work with source, as there is no source to jump to.

The M-x finder-commentary example shows that even non programming
users may need the source to get all the functionality that they
require. Of course it would be possible to ensure that the commentary
was copied into the .elc file, or alternatively, it could be cut out,
and kept, so that you could still view it even when the .el files were
gone. 

The core problem is that the Emacs is a lisp interpreter. The
distinction between "files required for compiling" and "files required
for running" is not clear with lisp as it is with C, for instance. My
own feeling is that binary distributions of emacs should always
include .el files, but not the C source for the lisp
interpreter. Which is what Emacs's own makefile installs. 

Phil

Re: Software/HD ecology

[Kai Großjohann]

Phillip Lord <p.lord@russet.org.uk> writes:

>>>>>> "Anil" == Anil Trivedi <anil@null.invalid> writes:
>
>   Anil> 2. Once the program compiles, and works fine, the user should
>   Anil>    be able
>   Anil> to delete all files that were needed in compiling but will not
>   Anil> be needed in running it, or in uninstalling it.
>  
> I think Kai's example showed the problem with this. 

Note that we might be talking cross purposes.  (Is that the right
idiom?)

If people download emacs-*.tar.gz, unpack it into, say /tmp/src, then
./configure --prefix=/usr/local; make; make install, then surely
afterwards /tmp/src can be deleted without any ill effects.

This has been said previously in this thread.  It might be what Anil
is referring to, I'm not sure.

The *.el and *.elc files installed in /usr/local are a different
beast entirely.  It's not good to delete the *.el files there -- we
agree on that.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Software/HD ecology

[Anil Trivedi]

Phillip Lord <p.lord@russet.org.uk> wrote:


>   Anil> 2. Once the program compiles, and works fine, the user should
>   Anil> be able to delete all files that were needed in compiling but will not
>   Anil> be needed in running it, or in uninstalling it.
>   
> I think Kai's example showed the problem with this...
> Personally I find an emacs without the .el files half baked...
> The core problem is that the Emacs is a lisp interpreter...

There is no problem here. If it is desirable to keep .el files in
Emacs, let us by all means keep them. Make them unremovable and have
the program issue a stern lecture and warning to anyone who tries to
override the protection!

That is however no reason to no provide tools to delete unneeded files,
in emacs or in hundreds of other programs. 

Let me add the following philosophical plug that I have been pushing
today: Unix was conceptualized for small systems and programs, where a
user needed and knew every file, where it came from, what it does.
Either he wrote it himself or copied it from a friend. Those times are
gone. We have hundreds of thousands of files, know nothing about them,
and routinely install packages that bring thousands of files. The
culture and the tools have not evolved to deal with this reality and
perhaps need to. 

Anil Trivedi

Re: Software/HD ecology

[Miles Bader]

Anil Trivedi <anil@null.invalid> writes:
> That is however no reason to no[t] provide tools to delete unneeded files,
> in emacs or in hundreds of other programs. 

Um, _someone_ has to write these tools, and deal with the resulting problems.

This seems to be the point you don't get -- regardless of whether it's
a good idea, it's not at all trivial.  It's easier if you plan on it
from the start, but this obviously doesn't help emacs!

-Miles
-- 
We live, as we dream -- alone....

Re: Software/HD ecology

[David Masterson]

>>>>> Kai Großjohann writes:

> Most important of all, it's not clear what to delete.  There would
> be *endless* arguments about which files to remove and which files
> to keep.  Emacs consists of 2297 files (on my system), it's very
> difficult to untangle dependencies on them.

Thus the need to "package-ize" Emacs.  Then, to uninstall Emacs, you
uninstall all the packages and uninstall the base Emacs.  The notion
is that recursion takes care of the packages.

> Then the ask how to send mail, and I tell them to type M-x
> finder-commentary RET smtpmail RET.  This command prints some
> documentation which is extracted from the beginning of the file
> smtpmail.el.

> But they don't have that file installed!

At which point, finder-commentary should probably say that that
package is not installed and (perhaps) point the user to the Internet
(mirror) sites where they might find the package.

> So, even the simple idea of `people don't want to look at the source
> code, people just want to run the resulting binary' has failed!

There's a chicken and egg view in this statement.  One view of Emacs
is that it is a program and, therefore, everything you want it to do
should "just be there".  Another view is that Emacs is an O/S where
packages are installed on top of it and, therefore, there needs to be
simple tools to add those packages in.

> That said, XEmacs has the so-called package system which is a very
> nifty thing indeed.  You install a base package of XEmacs which can
> do almost nothing at all, and then you start installing XEmacs
> packages which contain the Lisp code for various things.  It's very
> easy this way to upgrade the packages that you have installed.

> But then, a lot of XEmacs users install the Sumo tarball I think
> which just contains all available packages :-)  (Caveat: I'm not an
> XEmacs user, so what do I know what `a lot of XEmacs users' do!)

XEmacs actually has two tools for this.  It's been quite awhile since
I used the UNIX tool for managing packages in XEmacs.  My typical
environment is to use the Cygwin-like install tool on Windows-NT to
manage XEmacs and it's packages.  That tool is a separate program from
XEmacs and, so, you don't have a chicken and egg problem that (I
believe) XEmacs has on UNIX.  That is, on UNIX, when installing XEmacs
for the first time, there is the question of what do you install so
that you have enough functionality to install all the other packages?
Many people opt-out of answering that by just installing the Sumo, but
thereafter they can use the package tool in XEmacs.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Software/HD ecology (was Re:...Bug in Emacs 21.3.50)

[Bijan Soleymani]

Ajanta <ajanta@no.spam> writes:

> Actually I don't understand this equivalence. Makefiles routinely come
> with targets like "clean" which presumably deletes files like .log/.o
> and of course "install".  If they could have a few extra targets, like
> "superclean" or "EnglishOnly", that's a few extra lines. Why is that
> comparable with the clutter of tens of MB and 100's of files scattered
> around? If you can have "make install", why not "make uninstall" which
> would merely remove all the installed files and links?
> 
Most software I compile nowadays has a "make uninstall".
Also usually there is a distclean option that cleans very well.
As for the others most options belong in the configure step
like --without-this --with-that.

Bijan

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[David Combs]

In article <061220021433180478%ajanta@no.spam>, Ajanta  <ajanta@no.spam> wrote:
>[Deleted the xemacs group, but keeping comp.text.tex since this whole
>exercise is TeX-related for me]
>
>Andrew Choi <akochoi_NOSPAM_@shaw.ca> wrote:
>
>> Oh no, not again.  This patch will fix it:
>> 
>> Index: getopt.c
>> ===================================================================
>> RCS file: /cvsroot/emacs/emacs/lib-src/getopt.c,v
>> retrieving revision 1.21
>> ... 
>
>Thanks. I am sure this would have helped. Fortunately I was able to get
>the emacs 21.3.50 ...

Gnu-emacs 21.2 is as of march this year -- pretty ancient, no?

Where do you get something newer -- even beta or alpha?

(tarball, for solaris)

Thanks,

David

Re: Emacs 21.3.50 on Mac OSX 10.2.2

[Ajanta]

David Combs <dkcombs@panix.com> wrote:

> Gnu-emacs 21.2 is as of march this year -- pretty ancient, no? 
> Where do you get something newer -- even beta or alpha?
> (tarball, for solaris)

You "cvs" the source and then compile it. However, as I was able to get
pre-built binaries for mac os x, I can't help you directly.

Look at http://members.shaw.ca/akochoi-emacs/ for cvs instructions. You
obviously want to ignore any mac-specific advice that might be given
there.

A

Thanks to all (Re: Mac OSX TeX / To X11 or Not?)

[new2osx]

I am deeply appreciative of all the feedback and truly helpful answers.
Thank you all very much indeed. I have decided, actually made a short
list, as follows:

1. One spends a lot of time with the editor, so it is one personal
attachment I have and that happens to be Emacs. I am keeping the
terminal Emacs (21.1) that came with my OSX distribution, but will try
the GUI one too. I have a few questions; I posted those under a
different subject "Emacs 21.3.50 on Mac OSX 10.2.2".

2. For the time being at least I wont get X11 but will try to work with
the native aqua/quartz/display-pdf.

3. I'll get Gerben Wierda's teTeX. I'll probably use command line
pdftex but I'll also try TeXShop. In addition, I will try previe-latex,
auctex, reftex combo recoomended by a few posters.

4. I have noted the recommendations for diagrams but I'm going to
revisit this issue later, after I have gotten the basic setup going. 

A

Re: Thanks to all (Re: Mac OSX TeX / To X11 or Not?)

[David Kastrup]

new2osx <new2osx@no.spam> writes:

> I am deeply appreciative of all the feedback and truly helpful answers.
> Thank you all very much indeed. I have decided, actually made a short
> list, as follows:
> 
> 1. One spends a lot of time with the editor, so it is one personal
> attachment I have and that happens to be Emacs. I am keeping the
> terminal Emacs (21.1) that came with my OSX distribution, but will try
> the GUI one too. I have a few questions; I posted those under a
> different subject "Emacs 21.3.50 on Mac OSX 10.2.2".
> 
> 2. For the time being at least I wont get X11 but will try to work with
> the native aqua/quartz/display-pdf.
> 
> 3. I'll get Gerben Wierda's teTeX. I'll probably use command line
> pdftex but I'll also try TeXShop. In addition, I will try previe-latex,
> auctex, reftex combo recoomended by a few posters.

preview-latex will not run with a terminal Emacs.  And it may well be
that it may work just with X11: I do not know to what degree image
support would by now be included in the Cocoa version.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>