Date: Sun, 30 Jan 2000 16:51:44 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Josef Karthauser <joe@pavilion.net> Cc: current@FreeBSD.org, committers@FreeBSD.org, Jeroen Ruigrok van der Werven <asmodai@bart.nl>, Marcel Moolenaar <marcel@scc.nl> Subject: Re: More world breakage Message-ID: <200001302151.QAA61702@server.baldwin.cx> In-Reply-To: <20000130203936.A74352@florence.pavilion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30-Jan-00 Josef Karthauser wrote: > On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: >> >> > I don't think we should change yet another thing before a release. The >> > problem shouldn't have been created this close to a release in the first >> > place. We have to stop somewhere, and I think we should stop "fixing" right >> > here, right now unless there's a *really* good reason not to (IMO of >> > course). >> >> You're right. I guess the proper solution is to just back these changes out >> until after 4.0 when you can finish fixing up install side of 'world'. I just >> got ahead of myself a little. > > I've been thinking about this - being the one who made the original > commit! :) > There is now a problem for some people with the build chain due to > xinstall being dependant upon a function that has changed its name > for its file flags support. There is also a secondary question of > whether getflags/setflags are good names for these functions (based > as there were on getmode/setmode). I have no opinion on the function names used except that strflags() would be bad, IMO. > Thinking out loud: > > If we back out the name change (string_to_flags->setflags) we'll > bump into the buildchain problem again for people who've now got > a new xinstall dependant upon setflags. My main concern is people going from 3.x to 4.0. Since the xinstall binary on 3.x doesn't call a string_to_flags() function from libc but has it statically compiled in, the upgrade path should work fine for them. I'll test that tonight. If that path works fine, then the problem only exists for the people using fairly recent -current who have an xinstall binary that tries to use string_to_flags() from libc. Given, then, that they are all -current users, their being able to work around this is not too much to ask. I didn't originally realize that 3.x xinstall binaries didn't try to call the string_to_flags() function from libc. With that in mind, the upgrade path is only going to be broken for a few people who should be reading -current and thus know how to work around the problem, so I repeal my request for the changes to be backed out. My apologies. > Moving the functions back into libutil, from libc, is the wrong > thing to do, IMHO, because the problem here isn't one of which > library placement, it's one of function names. Libutil is the > wrong place for these functions, which is why I wanted them in libc > for the 4.0 release. Agreed. > It may be argued that we should back out _both_ commits and resurrect > bin/ls/stat_flags.c. Would this gain us anything? No. > I'm quite happy to DTRT(tm); I'm unsure that backing this change out > _is_ the right thing however. Can we discuss it some more first please? > > Joe -- John Baldwin <jhb@FreeBSD.org> -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001302151.QAA61702>