Summary: | multibuild.eclass: flock not available on OSX (GNU userspace) | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | MATSUI Tetsushi <VED03370> |
Component: | Prefix Support | Assignee: | Michał Górny <mgorny> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | prefix, ulm |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | OS X | ||
URL: | http://article.gmane.org/gmane.linux.gentoo.devel/85610 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
MATSUI Tetsushi
2013-04-20 11:20:04 UTC
multibuild_merge_root IMO shouldn't rely on userland_* stuff, instead it should test on availability of commands, e.g. lockf, flock, lockfile. Last but not least, it should probably use a generic method for locking, using the shell only (not requiring any external tools). e.g. touch waiting.$$ && until ln waiting.$$ waiting 2>/dev/null; do sleep 1; done && rm waiting.$$ do stuff rm waiting @ulm, you were the one suggesting using userland, weren't you? Any suggestions? @Fabian, thanks for the tip. I will think it thoroughly in the next few days. (In reply to comment #2) > @ulm, you were the one suggesting using userland, weren't you? Any > suggestions? Your original logic in multibuild_merge_root() was testing for availability of lockf to determine if it's BSD or GNU: + if type -P lockf &>/dev/null; then + # On BSD, we have 'lockf' wrapper. + tar -C "${src}" -f - -c . \ + | lockf "${lockfile}" tar -x -f - -C "${dest}" + else + [...] + cp -a -l -n "${src}"/. "${dest}"/ My suggestion was merely that you should test for GNU userland when you require the GNU version of commands (like cp -a). (In reply to comment #3) > My suggestion was merely that you should test for GNU userland when you > require the GNU version of commands (like cp -a). +1. For that, userland seems fine, since you have not much else to test that on (and should only happen for Gentoo/*BSD guys). If you stick that conditional within the shell-based portable lock code, you'll be fine on all (UNIX-like) Prefix platforms. (In reply to comment #4) > (In reply to comment #3) > > My suggestion was merely that you should test for GNU userland when you > > require the GNU version of commands (like cp -a). > > +1. For that, userland seems fine, since you have not much else to test > that on (and should only happen for Gentoo/*BSD guys). Well, the main reason for userland_ conditional was that BSD 'cp' was (is?) broken and didn't work correctly with '--no-clobber' (though it supports that option). > If you stick that conditional within the shell-based portable lock code, > you'll be fine on all (UNIX-like) Prefix platforms. At a third glance, the code looks fine. Are there any potential issues that I should be aware of? (In reply to comment #5) > Well, the main reason for userland_ conditional was that BSD 'cp' was (is?) > broken and didn't work correctly with '--no-clobber' (though it supports > that option). I now understand that > > If you stick that conditional within the shell-based portable lock code, > > you'll be fine on all (UNIX-like) Prefix platforms. > > At a third glance, the code looks fine. Are there any potential issues that > I should be aware of? Nope, apart from that you should make sure the try file and the actual lock file are on the same filesystem, but that should be easy to assure. FWIW, locking a file is racy (at least in theory) - while creating a directory is guaranteed to be an atomar operation by the kernel, therefore creating a directory to hold a lock is the better choice. http://www.linux-magazin.de/Ausgaben/2012/05/Bash-Bashing/%28language%29/ger-DE /just my 2ct Committed. @Fabian, I think the new locking code is causing deadlock sometime (I've seen one today, then bug 471168 may be related). Could you double-check it? It seems that $$ was responsible. I've replaced it with $BASHPID and hopefully everything will work fine now. |