Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
(I missed including the usr.sbin/Makefile change to remove rmt from SUBDIRS, changed locally)
The TODO: must be done before rmt is removed. And I think further discussion on -arch about this should occur, rmt is kinda a common thing for people that run tapes, and tapes are still alive.
rmt, rdump, rrestore all support something other than rsh(1) as a transport mechanism, ie ssh. Also if rmt goes you need to kill rdump, rrestore and fix the man pages. MFC'able depreication notices should go in first too.
ObsoleteFiles.inc | ||
---|---|---|
41 | need to remove /etc/rmt also |
@rgrimes this change was prompted by me trying to figure out what to do with the /etc/rmt symlink while working on pkgbase issues. Do you have any objection to starting with just removing that? (It exists to support remote mode in ancient UNIX tar commands.)
@emaste Yes I object especially if that is the basis for this change. Why are we messing with other software to fix a defeciency in pkg base? symlinks in /etc/ should be supported. My fear is that though you say /etc/rmt "is to support ancient tar commands" the reality is everyone using rmt probably refers to it via /etc/rmt and this is going to break if you remove it. Using the word ancient is poor taste, all things "Unix" are ancient :-) I am ancient also by your standards :-(.
How are the symlinks /etc/termcap, /etc/unbound, and /etc/aliases handled by pkgbase? You certainly can't go removing those.
@rgrimes there is no pkgbase deficiency that I'm trying to work around, it's just hoping to retire what appears to be a historical accident and remove the only binary executable in /etc.
See e.g. share/termcap/Makefile
etc-termcap: ${INSTALL_SYMLINK} -T "package=runtime" \ ${BINDIR}/misc/termcap ${DESTDIR}/etc/termcap
*sigh* usr.sbin/rmt/Makefile needs updated to do the proper packaging of rmt and your done?
rmt, rdump, rrestore all support something other than rsh(1) as a transport mechanism, ie ssh
We don't need rdump and rrestore for that though, it's true for plain dump/restore. It seems such usage should really be explained in the man page.
You need r{dump,restore} to talk rmt protocol to a remote tape drive, you can not just pipe over ssh to a remote tape drive.
Not precisely true, given that rdump is just a link to dump, but I see your point. Still we should document such use in the man page.
when dump/restore are invoked with the leading r they change behavior and speak "rmt". Yes, there is probably much documentaiton missing.
They don't actually check argv[0], remote mode is switched on by looking for : in the file argument.