Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Sep 2008 08:06:24 -0400
From:      Randy Pratt <bsd-unix@embarqmail.com>
To:        Ken Smith <kensmith@cse.Buffalo.EDU>
Cc:        freebsd-stable@freebsd.org, Kai Otto <kais.deliverymail@googlemail.com>, Ian Smith <smithi@nimnet.asn.au>
Subject:   Re: Fwd: FreeBSD 7.1 Content
Message-ID:  <20080907080624.078e7e13.bsd-unix@embarqmail.com>
In-Reply-To: <1220762797.29265.43.camel@bauer.cse.buffalo.edu>
References:  <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 07 Sep 2008 00:46:37 -0400
Ken Smith <kensmith@cse.Buffalo.EDU> wrote:

> On Sat, 2008-09-06 at 14:51 +1000, Ian Smith wrote:
> > I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is 
> > still the default browser in Options, available during installation from 
> > another vty.  So I was a bit surprised, on rebooting into my so far not
> > much configured 7.0, to find that it hadn't actually been installed.
> > 
> > It's a pretty small package, useful enough to at least read local docs, 
> > and would be handy installed from disc1 .. and maybe even by bootonly?
> 
> I'm actually planning to go in the opposite direction so to speak as far
> as sysinstall is concerned.  There are a couple projects in the works to
> replace sysinstall, along with the other nifty projects that roll
> FreeBSD into "another distro" in Linux-speak.
> 
> Basically this is something where one thing can't cater to everyones'
> needs/tastes/bikeshed-color.  All you need to do is tolerate this thread
> long enough to reach this message to see that...  :-)
> 
> I'm with Scott in that I like the "other distros" being around.  I don't
> think that necessarily means we shouldn't try harder.  But IMHO trying
> harder needs to be reflected in a new installer.  Lets face it,
> sysinstall s*cks...  For the type of folks who want the installer to do
> more than sysinstall does now sysinstall simply isn't the right tool (no
> offense intended).
> 
> That said I think "I" (as RE) am stuck with sysinstall being around for
> the forseeable future, even after we get a new installer, because some
> people are so accustomed to it and it fits their needs (again witness
> this thread...).  So I do have some plans for sysinstall but as I said
> above it'll be more towards a different direction than mentioned above.
> 
> The path I'm planning is based on these observations:
> 
> 	- Many people believe you should just use sysinstall to install
> 	  the baseline system, and any packages/ports installs should
> 	  be done post-install.  Its hard to say that point of view is
> 	  wrong.
> 
> 	- The baseline system and the ports are fundamentally different.
> 	  People should be aware of that from the beginning.
> 
> 	- At least some of the packages on the ISOs are stale within a
> 	  week of release at times; a bit longer than a week in most
> 	  cases but ...
> 
> 	- My plans for DVD sized media (still uncertain how that will
> 	  factor into 6.4/7.1) are to provide CDROM sized ISOs that have
> 	  no packages on them at all (giving people who don't have DVD
> 	  drives something they can still install from) and one DVD
> 	  sized ISO that has packages.
> 
> The path will be to finish what I started a while ago when I removed the
> X11 options in the "installation distributions" section of sysinstall by
> removing the last couple of tidbits that touch packages before you get
> to the "Would you like to view the list of available packages?" section
> of sysinstall (e.g. the offer to install Linux compatibility on i386).
> This will provide us with a clean separation of the baseline system from
> the packages.  After doing a baseline install you can choose to:
> 
> 	- reboot and install ports/packages when it comes back up
> 	- switch install media to be an FTP server and get a larger
> 	  selection of packages to choose from
> 	- use the available packages if you're installing from DVD
> 
> No matter which approach you use, you're clearly seeing a separation
> between the baseline system and the packages/ports.  If you want lynx or
> links or Gnome or KDE you're aware that they are packages/ports and
> simply select them.  If you didn't want them then you don't wind up with
> them sitting on your disk.  Basically I'm saying any of the things that
> may have been in the "Distributions" section of sysinstall before (X11
> stuff used to be in the Distributions) are now in the packages section
> along with all the other things that are packages.  And with the
> packages only being available on the DVD sized media we stop needing to
> deal with deciding what precious little amount of stuff is worthy of
> being on disc1 versus disc2/disc3/etc. and all the disc swapping that
> comes with CDROM sized media.
> 
> And for at least some arch's we *might* be able to move the livefs
> support back onto disc1 if there are no packages there for CDROM sized
> media - I haven't had a chance to check if that's still feasible.

Excellent summary!  It addresses things that have been discussed on the
lists many times.

The ports tree distribution tarball provided on the installation disks
is another area that needs some consideration.  I suspect that many
people aren't aware of the need for "adoption":

  http://myfreebsd.homeunix.net/hints_n_kinks/adoptportstree.html

Is it possible to provide/install the necessary file(s) along with
the ports tree such that cvsup/csup would be aware of the files
installed so that obsolete files can be removed when updating the ports
tree?  The same situation probably exists for the source tree
and the documentation tree.  Would it just be a matter of installing
the appropriate "checkouts.cvs:." files when the sources are
installed?

I've only done the adoption process one time and decided that its
easier to just csup a new trees right after booting the new system.

Additionally, I've never seen a clear way of synchronizing a
local ports tree to that used to create the "LATEST" packages. I've
had to resort to building my own package sets for the slow boxes
on the network.  I realize that this aspect diverges from the
subject of this thread but I do think some more thought should
be given to this aspect.

Anyway, the direction you're proposing for sysinstall/packages
seems to be the most logical approach.

Thanks to you and the rest of the Release Engineering teams for all
the work put into the releases!

Randy
-- 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080907080624.078e7e13.bsd-unix>