Date: Mon, 25 Aug 1997 12:52:13 -0400 (EDT) From: rdkeys@csemail.cropsci.ncsu.edu To: freebsd-hackers@freebsd.org Cc: rdkeys@csemail.cropsci.ncsu.edu () Subject: Suggestions from a unix dummy..... Message-ID: <9708251652.AA129381@csemail.cropsci.ncsu.edu>
next in thread | raw e-mail | index | archive | help
Thoughts or suggestions that might help clarify the muddied waters for
us unix dummies, like me......
We all agree FreeBSD is the best flavor of unix bar none, or we would
not be here, yup, yup, yup.
1. FreeBSD ftp installs are the greatest thing since apple pie, BUT,
synchronization is, at best a headache, and at worst a nightmare.
2. Clarity for the dummies is desired, AND clarity for the ftp scripts
is desired.
Applying unix dummies dunce cap and sitting on yon stool in the corner.....
What about setting up the ftp install scripts and the archive trees
something like.....
FreeBSD/x.x.x.x-release/
FreeBSD/x.x.x.x-release/binary
FreeBSD/x.x.x.x-release/sources
FreeBSD/current-stable/
FreeBSD/current-stable/binary
FreeBSD/current-stable/binary/archive/oldsnap-X
FreeBSD/current-stable/binary/archive/oldsnap-Y
FreeBSD/current-stable/sources
FreeBSD/current-development/
FreeBSD/current-development/binary
FreeBSD/current-development/binary/archive/oldsnap-X
FreeBSD/current-development/binary/archive/oldsnap-Y
FreeBSD/current-development/sources
FreeBSD/ports
FreeBSD/docs/
FreeBSD/bootdisks/
Move the releng thing into current-stable. It is a good idea, but
its nomenclature is confusing.
Move the development work from 3.0 into current-development. It is
a good idea, but 3.0 is not yet 3.0, but it is ``current-development''.
A VERSION file in appropriate directories would tell you the current
version number for any current tree, or release tree, and could be
parsed by the install scripts to confirm the validity of the tree,
if need be.
Add any new releases to the root FreeBSD level as x.x.x.y-release.
This is pretty much as is currently done.
Put the binary install chunks and trees down the /binary sections.
Put the sources down the /sources sections.
These are relative to their level as releases, current-stable, or
current-development.
Forget about snaps, except as archive trees for the normal time
snaps are kept around in the archive subdirectories, just for reference.
The naming blows up the install scripts if your install disk is only
a little out of sync. It is a good idea, but the nomenclature in
naming is marginal.
Put all the ports in one place, and make any port buildable on any
release or any current-stable or current-development box. Maybe
this would make many less headaches in out of sync ports. It should
be entirely possible in principle and probably in practice to make any
port build on any release from 2.1.7.1 up through the latest current
development system, IMHO. Practically, it should, especially if the
sources are brought in from a common starting distribution directory
or from standard internet repositories, as is currently done.
That way PORTS ARE ALWAYS CURRENT --- good for us dummies, yup, yup, yup.
That way, all the install scripts install from ONE AND ONLY ONE
pointer. You don't wind up with your snap vaporized a week down the
road. YOU ALWAYS GET THE CURRENT SNAP FROM ANY INSTALL DISK (verrrrrry
important and goooooood for us dummy folks --- saveum lotsa headscratchums).
If the install disk was old, the script could pull in a current kernel image
after the install and boot from that with defaults set from sysinstall
downloaded from the current tree. THAT WAY SYSINSTALL IS ALWAYS CURRENT.
THAT WAY YOUR KERNEL IS ALWAYS CURRENT.
When it comes time to split off a release and cast it in stone, then
split it off as the next release x.x.x.z-release, etc.
Boot disks should be made to always fetch something. Any particular release
bootdisk should always fetch its release. Any particular current-stable
or current-development bootdisk should always fetch its particular CURRENT
install tree. The date on a disk should be irrelevant for ftp installs.
It may be a bit of like asking for a make world to work first time, but,
IMHO, FreeBSD needs something to unconfuse the vagaries of its various
incantations. And, most importantly, any install disk should install
its current level, be it an official release, a current-stable snapshot,
or a current-development snapshot, regardless of how old it is. The install
script should always point to the one true release, current-stable or
current-development tree, parse the VERSION file and let the installer
know if a difference exists, and if the to-be-installed tree is newer,
confirm to install, or search the archive/snaps for the correct matching
install (I really can't fathom anyone wanting to install an earlier
tree in current versions).
All this may fall on deaf ears, but it sure would make life easier for
us dummies. But, I had to get it off my chest.....
Thanks
Bob Keys
rdkeys@csemail.cropsci.ncsu.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9708251652.AA129381>