Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Florian Haas wrote: > On 11/19/2009 03:53 PM, Eelco Jepkema wrote: >> With 8.3.5 source tarball I could just do 'make; make install' and >> everything would be fine. I would get sane defaults, files in expected >> locations (config in /etc, libs in /usr/lib/drbd, man pages in >> /usr/share/man, local state in /var/lib/drbd etc.). > > Except that few if any of these defaults were FHS compliant, not to > mention that they weren't configurable. True, i don't want to go back :). >> With 8.3.6 however you'll need to run the configure script. Doing this >> it's really hard to get the defaults of before back and just running >> './configure' will forget or not create certain directories. > > "Certain directories" isn't helping much here. Be specific. Which ones? Those would be the ones noted below. >> Attached is the output for just running ./configure without any options >> and the config.log that belongs to that. > > Both of which look fine. You are right if you mean by fine, it did its work without an error message. However, if you do this you end up with a drbdadm that gives warnings about symlinks to /var/lib/drbd on every command. I haven't tested the other userland tools for this but i don't count a binary that gives a warning on every use to belong in the category 'fine'. >> running 'make -C user install': >> mkdir -p //usr/local/var/lib/drbd > > #1, you're not supposed to do that. Using "make -C user install" > installs only the userland binaries which is perfectly fine if you build > an appliance and you know exactly how your home-rolled management > utilities will manage DRBD, but most users will also want the > integration scripts found in scripts/, so you should simply run "make > install" from the top of the extracted tarball. Or, actually "sudo make > install" as it's generally a good idea to not build as root. I know this installs the userland tools, I didn't do this by hand. running 'make install' on drbd source root as you describe did this, I just explained here where the error was, not the actual command i used. I thought I would highlight the problems i found from the make install output I added to my original message. > #2, that mkdir is fine as it uses a correct default localstatedir path. Well, yes and no. Yes, it creates the path as stated in the Makefiles as localstatedirpath but, since I mentioned that some sourcecode is hardwired to /var/lib/drbd, this localstatedirpath will, as far as I can tell, not be used by anything. >> running 'make -C scripts install': >> mkdir -p //usr/local/lib/ocf/resource.d/linbit >> >> While the correct directory seems to be /usr/lib/ocf/resource.d/ (at >> least on my system). > > I'll have to check the OCF standard on that. My hunch is that both > /usr/lib/ocf and /usr/local/lib/ocf are permissible in which case the > default would be correct (being in line with both OCF and FHS), but if > OCF does mandate /usr/lib/ocf specifically, we'll correct this. > >> Furthermore, the default for creating a kernel module, WITH_KM, is set >> to no by configure. I'm not sure if having kernel module not compiled by >> default is something users would expect from drbd source. > > As you may have noticed, DRBD is headed for being merged into the > mainline kernel, at which point building the out of tree module becomes > obsolete. That's the reason why we created the separate configure > option, and also set its default to "no". Ah, that is even better. That is a good reason for a default of no. >> Ultimately, i'm not a fan of installing to /usr/local/etc et.al because >> i don't believe many tools will be able to use them correctly? > > Use --prefix=/usr. > >> Debian >> init script fixer update-rc.d for instance won't find the drbd init >> script in /usr/local/etc/init.d/drbd. I would think the defaults for >> this would rather be just normal /etc and /etc/init.d. > > Use --sysconfdir=/etc. I know I can override the defaults, however, I was thinking that doing... ./configure; make all; make install ...would and should at least be likely (I know its not possible to account for all situations) to leave functioning software that wouldn't need tinkering one way or the other. With the /var/lib/drbd references in source fixed that should be possible though so we'll leave it at that. Best regards, Eelco Jepkema