Date: Sun, 30 Jan 2000 21:12:11 +0000 From: Brian Somers <brian@Awfulhak.org> To: Josef Karthauser <joe@pavilion.net> Cc: John Baldwin <jhb@FreeBSD.org>, Marcel Moolenaar <marcel@scc.nl>, Jeroen Ruigrok van der Werven <asmodai@bart.nl>, committers@FreeBSD.org, current@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: More world breakage Message-ID: <200001302112.VAA06647@hak.lan.Awfulhak.org> In-Reply-To: Message from Josef Karthauser <joe@pavilion.net> of "Sun, 30 Jan 2000 20:39:36 GMT." <20000130203936.A74352@florence.pavilion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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! > > This problem is the product of _two_ recent changes in -current > only. In -stable, and in -current before the end of December the > following tools: ls, rm, chflags, find, xinstall and mtree used > a common set of routines to manipulate file flags. These were > borrowed from bin/ls/stat_flags.c and statically compiled into each > tool. At the beginnig of January, because of the proliferation of > utilities using these functions, I moved them to libutil in -current. > There were however various objections to this change, on the basis > that libutil isn't a utility library as its name suggest, but has > a much more narrow definition relating to login related code. It > was proposed by Bruce to move these to libc and to change their > name to be in keeping with similar routines for manipulating file > modes (setmode/getmode). This was what I did last week, renaming > flags_to_string to getflags, and string_to_flags to setflags. I > missed the clash of name space in a couple of unrelated tools, like > mount_nfs, I agree that I should have been more careful here - > sorry. > > 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). > > 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. > > 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. > > It may be argued that we should back out _both_ commits and resurrect > bin/ls/stat_flags.c. Would this gain us anything? > > 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? I think that getflags()/setflags() should stay where they are, but I can't comment on the namespace pollution issue. If/When the functions are renamed, they'll probably break make world again (because the new libc and old install will be there for a while), but to be honest, this *is* current. I think the issue to focus on is the function names. > Joe > -- > Josef Karthauser FreeBSD: Take the red pill and we'll show you just how > Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@freebsd.org, joe@tao.org.uk] > > -- Brian <brian@Awfulhak.org> <brian@FreeBSD.org> <http://www.Awfulhak.org>; <brian@OpenBSD.org> Don't _EVER_ lose your sense of humour ! <brian@FreeBSD.org.uk> 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?200001302112.VAA06647>