Re: Increasing FreeBSD compatibility in mtree

On Mon, Sep 24, 2012 at 08:22:40PM -0500, Jeremy C. Reed wrote:
> On Mon, 24 Sep 2012, Brooks Davis wrote:
>
> > I am planning to import NetBSD's mtree into FreeBSD largely for the -C
> > and -N. I plan to follow up with an import of install and integration
> > into our installworld process.
>
> Sounds great. For what it is worth, we have been discussing ideas to
> better provide individual software (tools, libraries) as separate source
> packages (to make it easier for non-NetBSD developers/users to use
> NetBSD code). mtree was part of that list.
>
> > To make that practical I need to keep the new mtree as compatible at
> > the script and output level as possible, especially since I've had a
> > request to merge the new version to current release branches. I've
> > implemented all the missing features and made some FreeBSD specific
> > default changes. I am hoping the NetBSD community will consider
> > accepting many or most of them to increase commonality and decrease
> > maintenance work.
> >
> > I've posted a set of 13 patches from 19 commits to my FreeBSD web space:
> >
> > http://people.freebsd.org/~brooks/patches/nmtree/
>
> Very nice that you provided them individually. Having some FreeBSD
> specific code I think is fine, as I can understand it would be difficult
> to change existing specifications that some depend on for security.
>
> I think if there are no complaints in next week I can start testing and
> then applying these individually for you.
Great! Let me know if any need to be reapplied.
> > I would like to suggest one further change of renaming NetBSD's -i
> > option to something else, making the behavior of -i depend on the
> > target OS, and deprecating -i to allow me to essentially do the same
> > with FreeBSD's -i option (implemented as -j in
> > 05-4space-indent-r240756-r240765.diff).
>
> I may be reading it wrong, but it seems opposite of this. Do you want -i
> to be indent or do you want -i to be for setting special file system
> flags?
I think the most compatible option is for -i to be neither in the long
term. In the short term having it be "indent with a warning" on FreeBSD
and "set special file system flags with a warning" elsewhere. That
means existing scripts continue to work in the interim but eventually
the two actions (sans warning) have their own flags.
> Also do you plan to continue to maintain a custom version for -w? Should
> we consider the -w switch (actually the documented "some" is too vague
> for me). (I am not sure I like adding a switch that is documented just
> to be ignored for compatibility of other system.)
There might be something to be said for following FreeBSD's behavior
more closely in the -w case. It wouldn't be hard to emit the warning
and not emit [gu]id= keys, but the latter feels like a bad idea given the
following case:
$ ls -l mtreetest/
total 4
-rw-r--r-- 1 12345 brooks 0 Sep 20 16:39 xxx
-rw-r--r-- 1 root brooks 30 Sep 21 15:39 yyy
$ mtree -n -w -c -k uname -p mtreetest/
/set type=file uname=root
. type=dir uname=brooks
xxx
yyy
..
$
If you did an update with this spec from FreeBSD's mtree you would end up
making a file owned by root that wasn't previously! The NetBSD behavior
makes more sense.
$ nmtree -n -w -c -k uname -p mtreetest/
/set type=file uname=root
. type=dir uname=brooks
xxx uid=12345
yyy
..
$
Depending on the feedback I get from the FreeBSD community I might
consider implementing and deprecating the current FreeBSD behavior for
older FreeBSD releases. I don't see the point in implementing the
current error on name lookup semantic in the future, but I suppose
someone might be using it as a strange way to find if there are any
files without valid users.
> Thanks again for your patches and some improvements.
Thanks for looking them over!
-- Brooks