Re: Requirements for 1.1
David Engel writes ("Re: Requirements for 1.1"):
...
> I finally got around to checking if dpkg would do the right thing and
> it almost does. In some cases, there would be a very small window
> when a library could not be found by ld.so. Two changes in dpkg need
> to be made to totally eliminate this window.
>
> First, when dpkg backups an existing symlink before moving a new one
> into place, it renames the old symlink instead of copying it. The old
> symlink must be left as is until the new one can be renamed into
> place.
This can be done fairly easily, as symlinks are quite simple to copy.
I'll just copy the existing link to make the backup.
> Second, dpkg must rename the new shared library into place before the
> new symlink. If the symlink is done first, it could be left dangling
> until the shared library is done. I'll leave it up to Ian to decide
> how the proper ordering can be ensured.
The ordering is at the moment determined by the order of the files
found in the archive. It therefore seems sufficient to arrange for
the user to be able to specify to dpkg-deb what the order of the files
ought to be, but I'm not sure how general I need to make this.
This may be an application for the `external tarfile' option to
dpkg-deb, but it's not clear to me how to create a suitable tarfile.
Something involving find and cpio might do the trick, and perhaps
using lorder on the output of find would help. Hmm, any ideas
anyone ?
> (*) Yes, this contradicts what I've been saying all along about not
> including this symlink in the .deb file because ldconfig would create
> and delete it as necessary.
Whatever :-). ldconfig will presumably be just as happy with a link
made by dpkg as one made by itself.
Ian.
Reply to: