On Fri, Feb 04, 2000 at 01:22:49PM -0500, John Baldwin wrote:
>
> On 04-Feb-00 Ruslan Ermilov wrote:
> > On Fri, Feb 04, 2000 at 11:05:01AM +0000, Josef Karthauser wrote:
> >> On Fri, Feb 04, 2000 at 11:40:34AM +0200, Ruslan Ermilov wrote:
> >> >
> >> > > Might I advice some more time before we actually do something?
> >> > >
> >> > > What's all this rush-it-in before anyone can actually fix the larger
> >> > > problem?
> >> > >
> >> > I'm positive about this as well.
> >> >
> >>
> >> The main reason for the backout isn't the xinstall problem, as this
> >> is a non-problem (it only affects a small window of -current users).
> >>
> > Hmm, if you apply this patch, then there will be another (not so small)
> > window of -current users, having their /usr/bin/install depending on
> > setflags() in libc. What will happen (if we do nothing with Makefile.inc1)
> > is that at installworld /usr/bin/install will fail right after new
> > libc.so.4 will be installed at the first -fschg, because with the
> > current shape of Makefile.inc1, a host /usr/bin/install will be used
> > at installworld until we install src/usr.bin/xinstall.
>
> Umm, setflags() has not been in libc very long, so that is yet another
> small window of -current users. Besides, these are *-current* users, if
> they can't deal with -current, they shouldn't be running it. The upgrade
> path from -stable to -current is not affected by this patch.
>
Could you please provide then *right* instructions for UPDATING?
> > Please, before you do it, upgrade to -current (you're running 3.4-stable
> > for the moment, right?), with /usr/bin/install depending on setflags()
> > in libc, then apply your patch, make buildworld, and make installworld
> > _without_ DESTDIR, i.e. in / (installworld will work for DESTDIR=/xxx
> > case).
> >
> > The real solution would be to resolve the install-tools issue.
> > But the questions remain:
> > 1) should they be built in a host environment or in -current?
> > 2) and how to proceed in a non-self-hosting case (e.g. building
> > -current world for alpha on i386).
> >
> > Building install-tools in -current environment (with new libraries)
> > may not work with an older (host) kernel. Building them in a host
> > environment may not also work for bootstrapping reasons (e.g., you
> > can't build -current xinstall on a 3.x).
>
> It is already pretty much a given that you need a -current kernel to do
> installworld due to the signal changes. So, assume that the -current
> kernel is present. You can then statically build copies of xinstall, sh,
> install-info, and any other tools used during installworld at the
> beginning of installworld.
>
> > The second question is more difficult one, I don't know what to do here.
> >
> > What IMHO should be done ASAP:
> >
> > 1. Add install-tools stage to the Makefile.inc1. These tools should
> > be built in a host environment, linked statically, and only for
> > self-hosting case (BUILD_ARCH == MACHINE_ARCH), and then be used
> > at installworld.
>
> I don't think this needs to be in 4.0. xinstall is *NOT* broken for -stable.
> (I just upgraded a -stable machine to -current a couple of days ago and my
> only problem was with install-info, I had *zero* problems with xinstall.
>
*Sigh* If this would be in 4.0, you wouldn't have this install-info problem
when upgrading from 3.x to 4.0.
>
> > 2. Right after we resolve this issue, your patch (provided that you
> > fix errors Bruce pointed out), should be committed to make it
> > possible to compile -current xinstall in a host environment, e.g.
> > from 3.x (IMHO, the most important case).
>
> I think his patch can go in now. Since the names of the functions is up
> to date, it is best to not have them in libc, otherwise we'll have to bump
> libc's version number after we do finally settle on the appropriate names,
> which would be a Bad Thing(tm).
>
I'm not objecting about this patch, I really want install-tools issue
be resolved before 4.0-release.
--
Ruslan Ermilov Sysadmin and DBA of the
[EMAIL PROTECTED] United Commercial Bank,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.247.647 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
