On Saturday 14 July 2007 17:46, Steinar H. Gunderson wrote: > On Sat, Jul 14, 2007 at 05:37:49PM +0200, Frans Pop wrote: > > Please revert this breakage! just Passing it off to initscripts does > > not seem like the right solution here. > > I don't really understand you here. Mounting NFS volumes without > rpc.statd has been semi-broken for ages (ie. works by accident), > util-linux is removing NFS mount support, and something has to take > over. Is then the right fix to > > a) Add a line or two to initscripts to start rpc.statd in addition to > portmap, or > b) Remove mount.nfs, against upstream's explicit intentions, and let > _all_ NFS mounts break when the new util-linux hits unstable?
I'm not all that interested in what the right long-term fix is, I'm concerned about a change in nfs-common breaking something semi essential that has worked for ages, accidentally or not. If something like that is reported, IMHO the only correct course of action is first to make sure that the breakage is fixed, and then to start talking with maintainers of other involved packages about the correct structural fix and migration path, and only implementing your own change again _after_ other packages have made the necessary modifications. Do I understand correctly that the new util-linux is sitting in experimental? In that case it is pretty clear to me that it should *not* hit unstable until this has been sorted out. > Given how easy a) is, and how hard b) will break at some later stage, > I'm quite sure I'd prefer a). Actually, you can simply remove the > current check for $gss_or_idmap, and do "/etc/init.d/nfs-common start" > as soon as you see an NFS mount (currently signaled by signaled by > signaled by signaled by "portmap=yes"). It has nothing to do with easy or hard. A change in nfs-common is causing systems to break. This should be fixed ASAP, and with #432511 only at priority important, it does not look like I want to wait for any action there... Cheers, FJP
pgpsJEJSv31AH.pgp
Description: PGP signature
