[re-adding Michal; not sure he is a subscriber. It's usually best to reply-to-all rather than assume that all readers are on-list]
On 09/14/2016 02:10 PM, Warren Young wrote: > On Sep 14, 2016, at 7:49 AM, Peter Rosin <p...@lysator.liu.se> wrote: >> >> On 2016-09-14 11:33, Michal Privoznik wrote: >>> >>> ln -s $xml.in $xml.out >>> >>> However, I was looking into archive produced by 'make dist' the other >>> day and found out that the symlinks are not preserved. >> >> I believe that is for the benefit of supporting unpacking the release >> tarball on systems that do not support symlinks, or where symlinks are >> not as flexible as one might wish for. > > The question, then, is whether libvirt would ever be unpacked on such a > system. > > I’m barely aware of what libvirt does, but I think I can come up with a > plausible scenario: libvirt built from source on Cygwin. > > It appears from the home page that libvirt already supports Hyper-V, so a > naive user might decide to build it under Cygwin rather than whatever native > Windows toolchain is currently used for that case. (The reason being that > libvirt, coming from the Linux world, probably builds better under a > Unix-like environment.) Since NTFS symlinks have a number of unfortunate > limitations[1] and restrictions[2], the tarball almost certainly won’t unpack > correctly. Cygwin unpacks and handles symlinks just fine as one of the many things it emulates, so that's not the issue (note, however, that non-cygwin apps are generally unable to recognize cygwin symlinks, which are intentionally NOT done as NTFS symlinks because NTFS symlinks are not POSIXy). I'd be more worried if trying to unpack libvirt and build it with mingw, where you no longer have cygwin symlinks in the mix, and would indeed be limited to just NTFS symlinks. But I think that mingw ports of tar already take care of that, by turning symlinks in the tarball into file copies (where the link target was also in the tarball) or an error message (where the link target is unknown) (although I haven't actually tested what MSYS would actually do, so I welcome further comments from anyone with experience). And yes, libvirt is (cross-)built for mingw on Fedora already, as well as me getting ready to prepare a Cygwin distribution build of libvirt (both for the remote machine control aspect, and for the HyperV aspect). I'm less familiar with cross-building for mingw to know for certain whether symlinks in tarballs cause problems for mingw targets, or whether Wine emulation on Linux even handles symlinks. So that agrees with the notion of making tarballs as portable as possible by avoiding symlinks. On the other hand, maybe the GNU Coding Standards should be updated to state that avoiding symlinks is no longer required of GNU packages (it's entirely plausible that when automake first coded up the tar -h rule, years ago, there really were Unixy systems where either the file system or the tar program didn't handle symlinks as gracefully as desired, which is a different beast than today's mingw situation). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature