e2fsprogs: create com_err.h symlink in includedir
PATCH 1/1 e2fsprogs: create com_err.h symlink in includedir
After debian bug #192277, debian/rules started making a symlink to com_err.h in /usr/include. Now I have Fedora bug #550889 for the same issue, and perhaps it's time to make this symlink by default, rather than fixing it up in packaging steps?
---
debian/rules +0 -1
@@ -326,8 +326,6 @@ install-std: build ${INSTALL_PROGRAM} $(E2FSCK_STATIC) ${tmpdir}/sbin cp ${mandir}/man8/e2fsck.8 ${mandir}/man8/e2fsck.static.8 - ln -s et/com_err.h ${tmpdir}/usr/include
Quoted 6 lines · Eric Sandeen
After debian bug #192277, debian/rules started making a symlink to
com_err.hin/usr/include. Now I have Fedora bug #550889 for the same issue, and perhaps it's time to make this symlink by default, rather than fixing it up in packaging steps?Signed-off-by Eric Sandeen <[email protected]>
Pulled into the e2fsprogs tree, with the following change:
[ Changed by tytso to remove the explicit -s option; this will
default to creating a hard link by default, which slightly faster. If people want to use symlinks for all links during the install process, they can use configure option --enable-symlink-install. The reason for this change is that some file systems, like AFS, don't support symlinks, and AFS users complain when they can't build or install into AFS. So I don't want to use symlinks unconditionally without a way of switching things back and forth, and it's easier if we just make all links made during the install process to be hard links or sym links. ]
- Ted
Quoted 22 lines · Ted Ts'o
Quoted 6 lines · Eric Sandeen
After debian bug #192277, debian/rules started making a symlink to
com_err.hin/usr/include. Now I have Fedora bug #550889 for the same issue, and perhaps it's time to make this symlink by default, rather than fixing it up in packaging steps?Signed-off-by Eric Sandeen <[email protected]>Pulled into the e2fsprogs tree, with the following change:
[ Changed by tytso to remove the explicit -s option; this will
default to creating a hard link by default, which slightly faster. If people want to use symlinks for all links during the install process, they can use configure option --enable-symlink-install. The reason for this change is that some file systems, like AFS, don't support symlinks, and AFS users complain when they can't build or install into AFS. So I don't want to use symlinks unconditionally without a way of switching things back and forth, and it's easier if we just make all links made during the install process to be hard links or sym links. ]
Quoted 1 line
- Ted
Hm, now in a "make rpm" build which has source in one place and rpm build area in another:
/bin/ln: creating hard link /home/sandeen/rpmbuild/BUILDROOT/e2fsprogs-1.41.14-0.x86_64/usr/include/com_err.h' => /usr/include/et/com_err.h': Invalid cross-device link
so I'm not quite sure how to work around this.
Maybe in the end it does have to be packaging-specific, with the link created by the distro pkg scripts...?
-Eric
Quoted 28 lines · Eric Sandeen
Quoted 22 lines · Ted Ts'o
Quoted 6 lines · Eric Sandeen
After debian bug #192277, debian/rules started making a symlink to
com_err.hin/usr/include. Now I have Fedora bug #550889 for the same issue, and perhaps it's time to make this symlink by default, rather than fixing it up in packaging steps?Signed-off-by Eric Sandeen <[email protected]>Pulled into the e2fsprogs tree, with the following change:
[ Changed by tytso to remove the explicit -s option; this will
default to creating a hard link by default, which slightly faster. If people want to use symlinks for all links during the install process, they can use configure option --enable-symlink-install. The reason for this change is that some file systems, like AFS, don't support symlinks, and AFS users complain when they can't build or install into AFS. So I don't want to use symlinks unconditionally without a way of switching things back and forth, and it's easier if we just make all links made during the install process to be hard links or sym links. ]Quoted 1 line
- Ted
Hm, now in a "make rpm" build which has source in one place and rpm build area in another:
Quoted 6 lines
/bin/ln: creating hard link/home/sandeen/rpmbuild/BUILDROOT/e2fsprogs-1.41.14-0.x86_64/usr/include/com_err.h' =>/usr/include/et/com_err.h': Invalid cross-device linkso I'm not quite sure how to work around this.
Maybe in the end it does have to be packaging-specific, with the link created by the distro pkg scripts...?
Ted, your change broke any builds span 2 different filesystems.
Now what?
-Eric
Quoted 11 lines · Eric Sandeen
Quoted 9 lines
Hm, now in a "make rpm" build which has source in one place and rpm build area in another:
/bin/ln: creating hard link/home/sandeen/rpmbuild/BUILDROOT/e2fsprogs-1.41.14-0.x86_64/usr/include/com_err.h' =>/usr/include/et/com_err.h': Invalid cross-device linkso I'm not quite sure how to work around this.
Maybe in the end it does have to be packaging-specific, with the link created by the distro pkg scripts...?
Ted, your change broke any builds span 2 different filesystems.
I thought I fixed this with commit 1e082c62?
Which Makefile is breaking? Is this the one in lib/et/Makefile.in? It currently reads:
$(Q) (cd $(DESTDIR)$(includedir) ;\ $(LN) $(LINK_INSTALL_FLAGS) et/com_err.h . )
and I don't see how that could have generated the error you've cited above...
- Ted
Quoted 15 lines · Ted Ts'o
Quoted 11 lines · Eric Sandeen
Quoted 9 lines
Hm, now in a "make rpm" build which has source in one place and rpm build area in another:
/bin/ln: creating hard link/home/sandeen/rpmbuild/BUILDROOT/e2fsprogs-1.41.14-0.x86_64/usr/include/com_err.h' =>/usr/include/et/com_err.h': Invalid cross-device linkso I'm not quite sure how to work around this.
Maybe in the end it does have to be packaging-specific, with the link created by the distro pkg scripts...?
Ted, your change broke any builds span 2 different filesystems.
I thought I fixed this with commit
1e082c62?
Quoted 8 lines
Which
Makefileis breaking? Is this the one inlib/et/Makefile.in? It currently reads:$(Q) (cd $(DESTDIR)$(includedir) ;\
$(LN) $(LINK_INSTALL_FLAGS)et/com_err.h. )and I don't see how that could have generated the error you've cited above...
I had to return the "-s" back as well, but the current code looks OK. The chance of separate filesystems for /usr/include and /usr/include/et being used seems vanishingly small.
Cheers, Andreas
Quoted 6 lines · Ted Ts'o
Quoted 5 lines · Eric Sandeen
Quoted 5 lines
Hm, now in a "make rpm" build which has source in one place and rpm build area in another:
/bin/ln: creating hard link/home/sandeen/rpmbuild/BUILDROOT/e2fsprogs-1.41.14-0.x86_64/usr/include/com_err.h' =>/usr/include/et/com_err.h': Invalid cross-device link
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
so I'm not quite sure how to work around this.
Maybe in the end it does have to be packaging-specific, with the link created by the distro pkg scripts...?
Ted, your change broke any builds span 2 different filesystems.
I thought I fixed this with commit
1e082c62?
Oh, maybe you did; I didn't see any reply to my original problem report, and I didn't see the patch sent to the list (maybe I missed it?)
So I assumed it wasn't yet fixed, TBH I don't usually build cross-fs that way so hadn't actually retested, sorry. Seems like it should be fine now, thanks.
As for Andreas' comment:
Quoted 3 lines
I had to return the "-s" back as well, but the current code looks OK. The chance of separate filesystems for
/usr/includeand/usr/include/etbeing used seems vanishingly small.
my problem was actually during the RPM packaging, so a slightly different situation.
-Eric
Quoted 12 lines
Which
Makefileis breaking? Is this the one inlib/et/Makefile.in? It currently reads:$(Q) (cd $(DESTDIR)$(includedir) ;\ $(LN) $(LINK_INSTALL_FLAGS) et/com_err.h . )and I don't see how that could have generated the error you've cited above...
- Ted