On Thursday 17 May 2012 09:09:25 Jim Rees wrote: > Boaz Harrosh wrote: > > On second thought, You know, I'm not sure about this fix. > > A lot of times we install to a side folder, so we can later > tar and package the sub-folder without actually affecting > our live system. What will happen with the packagers that > are not RPM don't they rely on this? > > I would like to let the user to install nfs-utils on the > side and to not conflict with the running system. Someone > how knows what he is doing can override the Kernel path > to what he wants. Just as he will need to override the > nfs init scripts. > > So I would prefer if we can just create the $(DESTDIR)/sbin/ > > I think the makefiles already create $(DESTDIR)$(sbindir). The problem was > that you weren't using $(DESTDIR)$(sbindir), you were using > $(DESTDIR)/sbin. The patch sets $(sbindir) to /sbin, so everything should > just work. > > But I could be wrong, automake is a black box to me. i don't think that was the issue. the osd_login dir wasn't telling automake that it was installing anything (whether sbindir or /sbin or anywhere else), so this makefile didn't create the destdir automatically. now that automake knows we have things to install into $sbindir (regardless of its value), it knows it has to create it before trying to install things. it might have worked in the past for people because either (1) they didn't use DESTDIR into an empty path or (2) they weren't running in parallel so the other subdir (that installs `mount`) took care of implicitly creating $(DESTDIR)/sbin for them. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
