From: kaufman@eecs.nwu.edu (Michael L. Kaufman)
Subject: Lets make it easier on the new folks
Date: Mon, 27 Jan 1992 03:58:55 GMT
I have an idea. As more and more people get involved with Linux, they
will be going to ftp the software from the sites. I just tried to get the
software and there were about eleventy-dozen directories to go through. How
about lets make a big tar files with everything (including the diskwrite, and
shoelace utilities) that a new person who wants to get the works will need.
Or, if that would be too large, how about a file that contains a list of the
files. Just an idea.
Michael
--
Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on
kaufman | fire off the shoulder of Orion. I watched C-beams glitter in
@eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be
| lost in time - like tears in rain. Time to die. Roy Batty
From: h108373@cs.tut.fi (Hakkarainen Kimmo)
Subject: Re: Lets make it easier on the new folks
Date: 27 Jan 92 15:45:33 GMT
kaufman@eecs.nwu.edu (Michael L. Kaufman) writes:
> I have an idea. As more and more people get involved with Linux, they
> will be going to ftp the software from the sites. I just tried to get the
> software and there were about eleventy-dozen directories to go through. How
>about lets make a big tar files with everything (including the diskwrite, and
> shoelace utilities) that a new person who wants to get the works will need.
> Or, if that would be too large, how about a file that contains a list of the
> files. Just an idea.
The big-tar-file is not the best aproach because these files will not
fit in floppies.
I think that the list of programs and their locations should exist. The
promblem is that there is not the absolutely right place for every utility.
At the moment I have five directories for binaries. The first excuse is
that directories containing at least 1,4 MB of disk space are not easy
to back up. The second is the ease of update utilities in groups, (as
fileutils).
I think that everyone who is porting something should include a readme-file
to tar file. That would contain information about location or something
like that.
kimmo
--
Kimmo Hakkarainen (h108373@cc.tut.fi)
From: abc@banjo.concert.net (Alan B Clegg)
Subject: Re: Lets make it easier on the new folks
Date: 27 Jan 92 18:09:16 GMT
In article <H108373.92Jan27174533@naakka.cs.tut.fi>
h108373@cs.tut.fi (Hakkarainen Kimmo) writes:
>The big-tar-file is not the best aproach because these files will not
>fit in floppies.
Right. There must be smaller parts available, but each must be self-sufficient
and self-documenting.
>I think that the list of programs and their locations should exist. The
>promblem is that there is not the absolutely right place for every utility.
>At the moment I have five directories for binaries. The first excuse is
>that directories containing at least 1,4 MB of disk space are not easy
>to back up. The second is the ease of update utilities in groups, (as
>fileutils).
Yes, there is an absolutely right place. We just have to create it.
Obvisously, cat, dd, and related programs belong in /bin. mtools, less,
and relatives belong in /usr/local/bin. Now, do we cross-link /usr/bin and
/bin like SunOS has done? Do we put all "required-to-run-single-user" binaries
in /sbin? I would like to form a mailing list of people that are interested
in helping out in setting some standards for directory locations. The current
state of affairs *MUST NOT CONTINUE*
With the current state of affairs, I am almost 100% sure that nobody has the
exact same file structure! I have created a file system mirror on
banjo.concert.net in ~ftp/pub/Linux/Release with what I think the file system
should look like. Please look it over! It holds all sym-links to make
the system run, as well as all binaries that I could find, and source moved
into what I believe to be the correct places.
>I think that everyone who is porting something should include a readme-file
>to tar file. That would contain information about location or something
>like that.
Yes. Every tar file should contain information on where the binaries and
source should live. Many of the current binary distributions were created
from the file system root (tar cf thing.tar /usr/bin/thing*) and that is *NOT*
acceptible [IMHO, of course].
We have to created a standard environment for the common locations for
files, and it needs to occur soon.. [before 0.13??]
Please contact me via e-mail if you wish to have input on the formation of
standardized places and standardized methods of file distribution.
-abc
--
abc@concert.net Alan Clegg - Network Programmer
MCNC -- Center for Communications
From: tthorn@daimi.aau.dk (Tommy Thorn)
Subject: Comments to Directory Standard (banjo.concert.net)
Date: 28 Jan 92 14:53:29 GMT
I think that we should develop standards/recommendations for most things, like:
kernel patches, portede programs, directory structure, and so on. It would
ease the cooperations a lot. Of course, these are not enforceable.
Alan B Clegg writes:
Yes, there is an absolutely right place. We just have to create it.
Obvisously, cat, dd, and related programs belong in /bin. mtools, less,
and relatives belong in /usr/local/bin. Now, do we cross-link /usr/bin and
/bin like SunOS has done?
Not if it can be avoided. But what is the real difference between /bin
and /usr/bin?
I would like to form a mailing list of people that are interested
in helping out in setting some standards for directory locations. The
current state of affairs *MUST NOT CONTINUE*
Hear! Hear!
I have created a file system mirror on banjo.concert.net in
~ftp/pub/Linux/Release with what I think the file system should look like.
Please look it over!
Well, things like lesskey.man less.hlp zip* unzip mkdir mkfifo ..
surely doesn't belong in /usr/bin. The available less is configured
wrongly. less.hlp belongs, I think, in /usr/local/lib/less.hlp
zip* unzip in /usr/local/bin
mkdir mkfifo in /bin
AND NO link to any of these
Personally, I think that we should try to put things where they belong under a
"normal" unix, including any of the GNU utilities. We don't need any
/usr/local/gnu or /usr/gnu dirs, they are only for sites having the gnu stuff
as an alternative to the standard utilities. We should also avoid gxxx, like
in gld, perhaps with the notable exection of gcc.
Yes. Every tar file should contain information on where the binaries and
source should live. Many of the current binary distributions were created
from the file system root (tar cf thing.tar /usr/bin/thing*) and
that is *NOT* acceptible [IMHO, of course].
We need to make installation REAL SIMPLE AND FAST. I suggest the
following standard for distributing ported programs.
Everything should be contained in a [compressed] tar file with a:
- README, a short explanations of how this version differs from
the original, if it does, and how it was compiled.
- PREREQUIST, again which kernel, but also which version of the
original.
- Makefile, not for compilation, but for installation!! After having
checked that you agree with paths and so, you just type 'make install'
perhaps as root.
- Patches, context diff against the original.
- Binaries
- Optionally, manual pages, also with full path.
Kernel patches should also be a [compressed] tar file containing:
- README, describing what the patch does/is.
- PREREQUIST, a precise statement of which version of the
kernel the patches applies, and which, if any, patches that
was already applied.
Sources belong in /usr/src, linux sources in /usr/src/linux, etc.
Maybe we should split patches and binaries, but I don't like that, as you
would properbly end up having only one of either.
/Tommy
--
Tommy Thorn email: tthorn@daimi.aau.dk
Computer Science Department "People shouldn't work because they love it,
Aarhus University they should work because it hurts."
DENMARK -- Bob Sparacino, former Xerox executive