Re: New packages and cross-config.gnu
> I think that's a mistake. With su, we should have a new name for the
> weird Hurd version, because it is not backward compatible. But the
> Hurd sync is fully backward compatible, and there's no reason to have
> it under a new name.
Actually it's not fully backward compatible. As I was just reminded, the
libc `sync' function, which is what the fileutils sync uses (sync is in
fileutils, not sh-utils), is backward-compatible and thus not synchronous
(it passes a zero wait flag in file_syncfs).
> Either we should arrange to have the Debian sh-utils package not
> install sync on the Hurd, or (better) we should submit the Hurd
> features to the sh-utils maintainer and merge it.
Well, whatever. I don't think it is worth burdening the fileutils
maintainer with it.
The Hurd `sync' program (before I renamed it) is truly synchronous (though
of course it ought to be interruptible, modulo unpleasant bugs), and hence
does something different from fileutils sync does and it may from a pure
compatibility standpoint not actually be desireable to have this different
behavior by defualt under the same name. The new behavior is furthermore
only now available through a thoroughly Hurdish interface; if we want to
extend fileutils, we might consider adding a `syncfs' libc function that
takes a file name and the two flags args (sync() == syncfs("/", 1, 1)).
Aside from that incompatibility, I just added very recently (such that
noone has ever used them) file args and options for the RPC flags, because
they seemed useful features to me in my current environment of debugging a
flaky hurd. Like fsysopts, the new syncfs does things useful particularly
on the hurd and only available on the hurd, so it seems fine to me that it
be a separate hurd-specific program. (It's also completely obvious that
it's flat-out simpler for everyone not to have to dick with fileutils.)
Reply to: