both sys-apps/star and sys-apps/tar provide /usr/bin/tar. this is unacceptable. as sys-apps/star provides /usr/bin/star, it should be considered safe to "remove" /usr/bin/tar from sys-apps/star's installation file list.
ARGH! the afio Makefile SUCKS! I have the bash environment variable $I set to /local/int (I use it with $CDPATH) and this damn Makefile uses it because CFLAGS is hardcoded to: --8<-- CFLAGS = ${CFLAGS1} $1 $2 $3 $4 $5 $6 $7 $8 $9 $a $b $c $d $e $f $g $I --8<-- but I is commented out by default: --8<-- #I = -I. --8<-- so starting make with an empty environment works: --8<-- [root@prometheus(pts/10):afio-2.4.7]$ env -i make gcc -Wall -O2 -fomit-frame-pointer -DMEMCPY -DMKDIR -DVOIDFIX -DHAVEFCNTL -DHAVEMEMCMP -DDEFFMTCMD='"fdformat /dev/fd0H1440"' -DPRG_COMPRESS='"gzip"' -DHAVEFNMATCH -c -o afio.o afio.c afio.c: In function `incheckentry': afio.c:1553: warning: `linkp' might be used uninitialized in this function afio.c: In function `infill': afio.c:1602: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `inhead': afio.c:1724: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `openotty': afio.c:2857: warning: suggest explicit braces to avoid ambiguous `else' afio.c:2917: warning: suggest explicit braces to avoid ambiguous `else' afio.c:2980: warning: suggest explicit braces to avoid ambiguous `else' afio.c:2997: warning: suggest explicit braces to avoid ambiguous `else' afio.c:3062: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `out': afio.c:3275: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `outhead': afio.c:3559: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `outhead2': afio.c:3591: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `tocentry': afio.c:4124: warning: suggest explicit braces to avoid ambiguous `else' afio.c: In function `xfork': afio.c:4304: warning: suggest explicit braces to avoid ambiguous `else' gcc -Wall -O2 -fomit-frame-pointer -DMEMCPY -DMKDIR -DVOIDFIX -DHAVEFCNTL -DHAVEMEMCMP -DDEFFMTCMD='"fdformat /dev/fd0H1440"' -DPRG_COMPRESS='"gzip"' -DHAVEFNMATCH -c -o compfile.o compfile.c gcc -Wall -O2 -fomit-frame-pointer -DMEMCPY -DMKDIR -DVOIDFIX -DHAVEFCNTL -DHAVEMEMCMP -DDEFFMTCMD='"fdformat /dev/fd0H1440"' -DPRG_COMPRESS='"gzip"' -DHAVEFNMATCH -c -o exten.o exten.c gcc -Wall -O2 -fomit-frame-pointer -DMEMCPY -DMKDIR -DVOIDFIX -DHAVEFCNTL -DHAVEMEMCMP -DDEFFMTCMD='"fdformat /dev/fd0H1440"' -DPRG_COMPRESS='"gzip"' -DHAVEFNMATCH -c -o match.o match.c gcc afio.o compfile.o exten.o match.o -o afio afio.o(.text+0x6689): In function `syserr': : warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead afio.o(.text+0x6680): In function `syserr': : warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead [root@prometheus(pts/10):afio-2.4.7]$ --8<-- can we "catch" these things in the ebuild?
I *hate* bugzilla for advancing to the next bug after committing a change for a a bug >:-(
Can we move the second comment to bug #33094 somehow?!
actually, unless you have an older version of tar installed, it uses /bin/tar while star uses /usr/bin/tar
yup, you're right, sorry. the problem actually is that "which tar" ("type -p tar") says "/usr/bin/tar" instead of "/bin/tar", even if my path has "/bin" before "/usr/bin". anyway, I really think it's confusing to have two tar-binaries on the system, so please prevent star's /usr/bin/tar from being installed. thanks!
*** Bug 60030 has been marked as a duplicate of this bug. ***
*** Bug 66855 has been marked as a duplicate of this bug. ***
note that they both install /usr/sbin/rmt also
*** Bug 69117 has been marked as a duplicate of this bug. ***
Note that the star binary is also not syntax-compatible with GNU tar, which CAN break some init/rc scripts, for example it breaks the unpack of the udev device tarball in /sbin/rc (line 230ff). This COULD render a system non-bootable if the old-style /dev entries are not sufficient.
lostlogic, will you do something about it? if not, would you want _me_ to do something about it? :)
*** Bug 69504 has been marked as a duplicate of this bug. ***
*** Bug 70490 has been marked as a duplicate of this bug. ***
*** Bug 71518 has been marked as a duplicate of this bug. ***
*push* any news here?
*** Bug 80859 has been marked as a duplicate of this bug. ***
*** Bug 82130 has been marked as a duplicate of this bug. ***
*** Bug 89854 has been marked as a duplicate of this bug. ***
I ran into an error described in Bug 82130 and saw that it was deemed a duplicate of this one. Reading through this report, I fixed my problem by editing: /var/tmp/portage/kdevelop-3.1.2/work/kdevelop-3.1.2/parts/appwizard/common/Makefile ...and changing: TAR = gnutar ...to: TAR = tar ...then doing: ebuild /usr/portage/dev-util/kdevelop/kdevelop-3.1.2.ebuild compile ebuild /usr/portage/dev-util/kdevelop/kdevelop-3.1.2.ebuild install ebuild /usr/portage/dev-util/kdevelop/kdevelop-3.1.2.ebuild qmerge
well, it's definitely not a kdevelop-only problem. Bumping this is a good thing though. This bug is getting rather old now, looks to me we don't actually need a *solition*, just a *decision* either way would be beneficial. My humble opinion: tar == /bin/tar == /usr/bin/tar == GNU tar star==star wherever it lives; call it by its name or symlink manually if you want it. As suggested in the initial bug report.
(In reply to comment #21) > My humble opinion: > tar == /bin/tar == /usr/bin/tar == GNU tar Not quite. tar is always the "system" tar. Eg. have a look at real Unix systems like Solaris or HP-UX. There, "tar" is (close to) never GNU tar. For this reason, it would be nice to have symlink gtar -> /bin/tar, so that it's easily selectable, which tar is to be used. Have a look at bug 93816 which I just filed.
I was talking about Linux, which, even if you don't follow Mr Stallman, is GNU/ Linux in the sense of kernel+GNU utils in virually all incarnations; it's quite sane for scripts to expect tar to be gtar (and if you avoid GNU-isms you can still keep things portable). I'm not sure how HP/UX and others (IRIX and AIX do similar things) handle broken symlinks in core system utilities at boot time, but symlinking to /bin/tar should NOT be done here because /usr might not be mounted when /bin/tar is needed, as in the abovementioned case of untarring the udev device tarball. (Symlinks to /usr/bin/tar are fine though, obviously.)
(In reply to comment #23) > I was talking about Linux, which, even if you don't follow Mr Stallman, is GNU/ > Linux in the sense of kernel+GNU utils in virually all incarnations; it's quite > sane for scripts to expect tar to be gtar No, it's not. Sane scripts should expect a posix tar. If GNUisms are expected, scripts should select a GNU tar. Now, I of course do now that in present time that is just wishful thinking. > I'm not sure how HP/UX and others (IRIX and AIX do similar things) handle broken > symlinks in core system utilities at boot time, but symlinking to /bin/tar > should NOT be done here because /usr might not be mounted when /bin/tar is > needed, I don't follow or understand that. Suppose /usr might not be mounted, there would still be the /bin/tar executable/binary. But as soon as /usr would be mounted, there might be a gtar "compatability" or maybe convenience link.
*** Bug 94481 has been marked as a duplicate of this bug. ***
Reassigning to base-system.
base system does not maintain tar nor do we care about it
(In reply to comment #27) > base system does not maintain tar nor do we care about it Then please fix metadata.xml # cat /usr/portage/app-arch/tar/metadata.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> <pkgmetadata> <herd>base-system</herd> </pkgmetadata>
typo on my part ... i meant 'star' not 'tar' base system does not maintain star nor does it care about it
(In reply to comment #29) > typo on my part ... i meant 'star' not 'tar' Oh, I see. :-) Well, this package needs maintainer.
*** Bug 95618 has been marked as a duplicate of this bug. ***
Unsolved for 1 1/2 years, no maintainer and still causing just troubles. What about hard-masking this? :/
Fixed in CVS, thanks.
*** Bug 96298 has been marked as a duplicate of this bug. ***
Still breaks kdevelop, even with star-1.5_alpha50.ebuild. :-(
Created attachment 61388 [details, diff] Reposting foo patch that excludes gnutar being merged
Created attachment 61389 [details] Reposting ebuild using patch
This should be fixed in -r1. Thanks a lot.
*** Bug 127196 has been marked as a duplicate of this bug. ***
