cvs commit: doc/en_US.ISO8859-1/books/handbook/desktop chapter.sgml doc/en_US.ISO8859-1/books/handbook/linuxemu chapter.sgml

[Alexander Leidinger]

On Mon, 12 Dec 2011 18:28:43 -0800 Doug Barton <dougb at FreeBSD.org>
wrote:

> On 12/10/2011 13:29, Nathan Whitehorn wrote:
> > On 12/10/11 15:06, Manolis Kiagias wrote:
> >> On 10/12/2011 10:40 μμ, Alexander Leidinger wrote:
> >>> On Wed, 7 Dec 2011 21:32:06 +0000 (UTC) Manolis Kiagias
> >>> <manolis at FreeBSD.org>  wrote:
> >>>
> >>> CCing re@, emulation@ and nwhitehorn@ due to a possible impact in
> >>> the upcomming release.
> >>>
> >>>>    Modified files:
> >>>>      en_US.ISO8859-1/books/handbook/desktop chapter.sgml
> >>>>      en_US.ISO8859-1/books/handbook/linuxemu chapter.sgml
> >>>>    Log:
> >>>>    Use /compat/linux/proc instead of /usr/compat/linux/proc as
> >>>> the mount point of linproc in the examples, since:
> >>>>
> >>>>    - linux_base always installs to /compat and creates it as a
> >>>> directory if it does not exist as a symlink
> >>>>    - Custom installations (not done by sysinstall(8)) may not
> >>>> have /compat at all
> >>>>    - The linuxemu chapter uses /compat anyway (except a single
> >>>> example, fixed)
> >>>>    - The new bsdinstall(8) does not create /compat either as
> >>>> directory or symlink
> >>> Looks like a bug in bsdinstall (and linux_base) to me. What you
> >>> write here means that a new release with bsdinstall instead of
> >>> sysinstall may cause problems where /compat is in a small
> >>> partition and /usr in a big partition (even if it creates a big
> >>> one by default, an user may change this). I suggest to fix
> >>> bsdinstall before the release of 9.0. It also changes what is
> >>> expected by long-term users.
> >>
> >> Yes, this was discussed in the PR (see
> >> http://lists.freebsd.org/pipermail/freebsd-doc/2011-December/019270.html
> >> ). I think the best and safer way would be for bsdinstall to create
> >> the link if possible.
> > 
> > This is very easy to do, and the correct place is in
> > /usr/src/usr.sbin/bsdinstall/scripts/config. I don't have a good
> > sense of what the correct logic is, however, and so would
> > appreciate either guidance or patches from emulation-types.
> 
> I don't understand why the linux_base ports are not sorting this out
> on their own. Why should this be a function of the installer?

The current state:
 - the kernel has a hardcoded /compat/linux
 - the ports framework (not the linux_base port) does a
   mkdir -p $PREFIX before the install
 - the PREFIX for the linux_base ports is /compat/linux (POLA)

The only part where we could do something in the port, is for the
PREFIX. Now... what are the implications to change this?
 - ports exp-run and commit and ports-tree-retagging and
   rebuilding of the ports for the release
 - users which see a different prefix than they are use to
 - a mess in the linux_base port to determine every
   possibility what the user did to /compat and to try to do
   the right thing

The last item is the most critical IMO. Personally I had once 2
different linux bases in /compat (activated by changing a link). I do
not expect much users like this, but the point is, that we do not know
what an user has in /compat, so messing around with it is dangerous.

One thing what we could do is to check in the linux_base port
if /compat is a symlink or not. If it isn't we error out and tell the
user to fix it. But then... is this still POLA? In cases where /compat
is a directory already, nothing bad will happen during an update, so
no need to error out (one of our credos is "features, not policies"). I
expect that in most cases it is already a symlink (when sysinstall was
used to install a system, which should be true for the majority of
normal users).

I'm open to your suggestions.

Bye,
Alexander.

-- 
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137