.specfile infirmity - link failed - Invalid cross-device link
R P Herrold
1. I was building a later abi-word, to see how it so coming
along. For space management, I have /usr and /usr/share on
different devices.
Filesystem 1k-blocks Used Available Use%
Mounted on
/dev/hda5 605164 541208 33216 95% /
/dev/hda1 29249 2848 24891 11% /boot
/dev/hda8 495876 9240 461035 2% /tmp
/dev/hda6 1511968 1299164 135996 91% /usr
/dev/hda7 1511968 1008592 426568 71% /usr/share
/dev/hda9 495876 127549 342726 28% /var
/dev/hda10 579376 16436 533508 3% /var/tmp
none 63120 0 63120 0% /dev/shm
/dev/hdb3 4569856 3461596 876124 80% /var/ftp/pub/mirror
2. The .specfile includes in part this stanza:
# Manual fixes to Abi package
# Fixes Abi start script
perl -p -i -e "s|$RPM_BUILD_ROOT||" \
$RPM_BUILD_ROOT%{ABIPREFIX}/AbiSuite/bin/AbiWord
# Fixes for symlink in {prefix}/bin
mkdir -p $RPM_BUILD_ROOT%{prefix}/bin
ln $RPM_BUILD_ROOT%{ABIPREFIX}/AbiSuite/bin/AbiWord \
$RPM_BUILD_ROOT%{prefix}/bin/abiword
3. Here is the error:
$ sudo rpm -Uvvvh /usr/src/redhat/RPMS/i386/abiword-0.9.6.1-1.i386.rpm
<snip>
D: fini 100755 2 ( 0, 0) 0 /usr/bin/abiword;3c462daa D: undo
100755 2 ( 0, 0) 1859
/usr/share/AbiSuite/bin/AbiWord;3c462daa GZDIO: 954 reads,
7814040 total bytes in 2.527 secs error: unpacking of archive
failed on file /usr/bin/abiword;3c462daa: cpio: link failed -
cross-device link
... and it dies off here.
4. ... How _should_ this be packaged? I try to avoid perl
entirely in packaging, for (theoretically) it may not always
be present. Not usually true with Linux, but in HP-UX, true
enough.
The link fixup is more troubling; an explicit ln -s might
help, as might generating a ../ relative path.
Thoughts?
-- Russ Herrold
_______________________________________________
Rpm-list mailing list
Rpm-...@redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list
Sergey Ostrovsky
<--snip
> The link fixup is more troubling; an explicit ln -s might
> help, as might generating a ../ relative path.
>
> Thoughts?
>
> -- Russ Herrold
Well, you've got the answer already -
A group of hard-linked files have the same inode#.
Inode#, in turn, makes no sense outside of the
filesystem it belongs to. IOW, it's not unique across
filesystems.
That's precisely what cross-device link means.
Thus ln -s is your only solution.
HTH
Sergey Ostrovsky.
R P Herrold
> On Wednesday 16 January 2002 09:02 pm, you wrote:
> <--snip
> > The link fixup is more troubling; an explicit ln -s might
> > help, as might generating a ../ relative path.
>
> Well, you've got the answer already -
>
> A group of hard-linked files have the same inode#.
> Inode#, in turn, makes no sense outside of the
> filesystem it belongs to. IOW, it's not unique across
> filesystems.
> That's precisely what cross-device link means.
>
> Thus ln -s is your only solution.
That turns out not to work -- it still does not build cleanly.
Instead, I initially used an expedient soluition of cp'ing the
binary across for proof of function. That took a couple of
hours because the magnitude of the package resulted in a
hourlong rebuild process.
Long term, I will move a ln -s into a post-install script, and
add the corresponding post-uninstall script. I believe this
is a 'more proper' approach.
-- Russ herrold
Jeff Johnson
Yup.
>
> 4. ... How _should_ this be packaged? I try to avoid perl
> entirely in packaging, for (theoretically) it may not always
> be present. Not usually true with Linux, but in HP-UX, true
> enough.
>
> The link fixup is more troubling; an explicit ln -s might
> help, as might generating a ../ relative path.
Yup. The best rule at the moment is
Never use a hardlink to a file not in the same directory.
There are execeptions, of course, glibc-common is about to become a painful
counter example, where hardlinks are going to be used to reduce the
size of the package by ~60 Mb by using hardlinks to files in other
directories. Yes, EXDEV is still not handled by rpm.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
j...@jbj.org (j...@redhat.com)
Chapel Hill, NC
Jeff Johnson
>
> Long term, I will move a ln -s into a post-install script, and
> add the corresponding post-uninstall script. I believe this
> is a 'more proper' approach.
>
That breaks --verify <shrug>.
The better fix is in %install IMHO.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
j...@jbj.org (j...@redhat.com)
Chapel Hill, NC
_______________________________________________