Joerg Schilling writes: > Don Cragun <don.cragun at sun.com> wrote: > > > The project team has made minor updates to the proposal to address > > concerns raised by Darren, Garrett, and internal project team members. > > (GNU rmt will move from /usr/sfw/libexec/grmt to /usr/lib/grmt instead > > of /usr/libexec/rmt, man page links will be placed in > > As I mentioned already, grmt is not needed as the rmt program from star > is replacing /etc/rmt ans this rmt implementation is a true superset of the > functionality of all known rmt implementation.
I've taken a look at the GNU tar documentation, and unless I'm misunderstanding this, it looks like this issue has gotten pretty confused, and it seems that we need some technical input from the project team. First of all, there doesn't appear to be a GNU variant of "rmt." Instead, GNU tar comes with a copy of the original BSD rmt, just as we already have. Secondly, as there doesn't appear to be a variant here, issues about replacing it or preserving the GNU-ness seem to be misplaced. We should just discard it as unnecessary. The *one* important issue is the one we've actually trampled into the ground, and that's the issue about the location. According to the GNU documentation, /usr/libexec/rmt isn't negotiable. My guess would be (and I haven't looked at the sources) that they try /usr/libexec/rmt first and then historical /etc/rmt when invoking it. On that theory (project team: please verify), both delivering as /usr/libexec/grmt and as /usr/lib/grmt are wrong, because nothing will look there for this helper binary. It won't be compatible, because the path is effectively part of the wire protocol. If that's correct, then we should either deliver /usr/libexec/rmt as a symlink or (perhaps better yet) do nothing. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
