From owner-freebsd-current Sun Jan 30 13:12:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from awfulhak.org (dynamic-123.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.251]) by hub.freebsd.org (Postfix) with ESMTP id A5AC6152C9; Sun, 30 Jan 2000 13:12:28 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA78967; Sun, 30 Jan 2000 21:12:18 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA06647; Sun, 30 Jan 2000 21:12:11 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200001302112.VAA06647@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Josef Karthauser Cc: John Baldwin , Marcel Moolenaar , Jeroen Ruigrok van der Werven , committers@FreeBSD.org, current@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: More world breakage In-Reply-To: Message from Josef Karthauser of "Sun, 30 Jan 2000 20:39:36 GMT." <20000130203936.A74352@florence.pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jan 2000 21:12:11 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message