> 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. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]
>
>
--
Brian <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<http://www.Awfulhak.org> <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour ! <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
