(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
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
