why is my symlink gone????

[Jeffrey Johnson]

(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.
> 

Yup.

> 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.

hth

73 de Jeff