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.
> 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.
> 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).
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
