Hi, Yves-Alexis Perez <corsac@debian.org> (2015-12-03): > dpkg behavior is to preserve as hard as it can the current layout of the > filesystem wrt. symlink to directories: it will try not to replace a > symlink by a folder or even the opposite. > > In debootstrap early stages, dpkg is not used (because not yet installed > in the target), but a custom implementatin using dpkg-deb|tar or ar is > used. Unfortunately, this implementation doesn't follow dpkg behavior, > and will happily replace a symlink by a dir. > > I'm using debootstrap in a custom way where I need to create some > symlinks beforehand (for example some multiarches dirs like lib -> lib64 > in / and /usr), it works fine with dpkg, but not with debootstrap early > extract. > > Would it be possible to replace the tar call in extract_dpkg_deb_data > with tar -hxf so it will follow symlinks instead of replacing them? While I don't have thought about this particular issue (yet…), I'd like to point out that debootstrap is supposed to be working on as many platforms as possible, so any flag addition (to tar or something else) has to be carefully checked. GNU tar vs. BSD tar comes to mind. Looking at bsdtar(1): | -c | Create a new archive containing the specified items. The long option | form is --create. | | -r | Like -c, but new entries are appended to the archive. Note that this | only works on uncompressed archives stored in regular files. The -f | option is required. The long option form is --append. | | -h | (c and r mode only) Synonym for -L. | | -L, --dereference | (c and r mode only) All symbolic links will be followed. Normally, | symbolic links are archived as such. With this option, the target of the | link will be archived instead. so BSD tar wouldn't get the fix for your usecase? (Inspecting its code, ./tar/write.c is where symlink_mode is used, and only when writing an archive.) Looking at GNU tar I read: | -h, --dereference | follow symlinks; archive and dump the files they point to I wasn't exactly sure about “dump” but src/extract.c's check on dereference_option seems to suggest that means tar -hxf would work; out of curiosity, did you test the proposed change? Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature