Date: Sun, 30 Jan 2000 20:39:36 +0000 From: Josef Karthauser <joe@pavilion.net> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Marcel Moolenaar <marcel@scc.nl>, Jeroen Ruigrok van der Werven <asmodai@bart.nl>, committers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: More world breakage Message-ID: <20000130203936.A74352@florence.pavilion.net> In-Reply-To: <200001290130.UAA42086@server.baldwin.cx> References: <002301bf69df$bd24eb00$0301a8c0@adm.scc.nl> <200001290130.UAA42086@server.baldwin.cx>
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? 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] 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?20000130203936.A74352>