why is my symlink gone????

Jeffrey Johnson n3npq at me.com
Mon Jan 9 01:03:41 CET 2012

(text copied verbatim into the #913572 as justification)

On Jan 8, 2012, at 6:45 PM, glen wrote:

> On 01/09/2012 01:11 AM, Jeffrey Johnson wrote:
>> This is a hard link to a symlink which is pretty obscure functionality.
> nevertheless, it's quite useful when optimizing for packaging speed
> when you develop huge packages, you would appreciate faster repackaging

If you mean the speed with which rpm build produces multiple
sub-pkgs, multi-threading likely is higher throughput than
most anything else: all the digests have to be calculated,
and that means all the content needs to be read, so there's
likely little I/O savings.

Dunno: the right approach is to do the measurement rather than
guess at a performance speedup.

Note that rpm-5.x has other performance issues that scale
as some power of the #files that also slow down rpm build
packaging with huge numbers of files (like kernel or texlive).

> so instead of copying data from %build -> %install tree, one can do hardlinks to speedup the process:

But calculating the digests is gonna read the content anyways: there's
some chance that the copied buffers will still be in cache.

Off-hand, its likely that all hard linked files will have their
digest computed repeatedly by rpmbuild. *shrug*

Meanwhile the flaw here is a hard linked symlink: avoiding I/O there is pointless
(but you do have to be careful to use hard links only on files, never on symlinks)

> cp -l build.txt $RPM_BUILD_ROOT/cp-test && l=l && rm -f $RPM_BUILD_ROOT/cp-test
> cp -a$l bin help lib license plugins $RPM_BUILD_ROOT%{_appdir}
> here it makes feature test if srcdir and $RPM_BUILD_ROOT are same disk, and enables hardlinking
> now if there is a symlink in a tree, it gets affected by this bug.


> also: in rpm package there is packaged only one instance of the hardlink (one in $RPM_BUILD_ROOT),
> imho should decide on that actual number, not what it sees from filesystem

There are other issues such as when there are hard links outside of $RPM_BUILD_ROOT.

There is no tag that carries st->st_nlink in rpm metadata. Instead st->st_nlink
is computed by looking for identical {dev,ion} pairs for the 1-2 places where
blink needs to be displayed by rpm.

Might not be too hard to fix … just not sure whether the gain is worth the risk
of breaking something else. Handling "partial hardline sets" was very hard to get right.


73 de Jeff

More information about the pld-devel-en mailing list