33119 2003-11-09 22:57 0000 /usr/bin/tar: sys-apps/star conflicts with sys-apps/tar 2006-03-22 09:43:52 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED P2 normal --- 1 wschlich@gentoo.org slarti@gentoo.org andre.hinrichs@gmx.de andres.becerra@gmail.com askwar@digitalprojects.com bakkerh@shaw.ca chris@realcomputerguy.com emmi3@gmx.de gentoo@nephros.org greg_g@gentoo.org j-gentoo@gazonk.org mholzer@gentoo.org sal@stodge.org satya@gentoo.org seemant@gentoo.org sguarin@fi.uba.ar wcc@techmonkeys.org wschlich@gentoo.org 2003-11-09 22:57:06 0000 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. wschlich@gentoo.org 2003-11-09 23:53:35 0000 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? wschlich@gentoo.org 2003-11-10 00:07:11 0000 I *hate* bugzilla for advancing to the next bug after committing a change for a a bug >:-( wschlich@gentoo.org 2003-11-10 00:09:02 0000 Can we move the second comment to bug #33094 somehow?! vapier@gentoo.org 2003-11-10 06:30:11 0000 actually, unless you have an older version of tar installed, it uses /bin/tar while star uses /usr/bin/tar wschlich@gentoo.org 2003-11-10 06:37:51 0000 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! vapier@gentoo.org 2004-10-09 23:51:55 0000 *** Bug 60030 has been marked as a duplicate of this bug. *** carlo@gentoo.org 2004-10-13 11:18:26 0000 *** Bug 66855 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-25 20:01:31 0000 note that they both install /usr/sbin/rmt also carlo@gentoo.org 2004-10-27 06:03:12 0000 *** Bug 69117 has been marked as a duplicate of this bug. *** gentoo@nephros.org 2004-10-29 10:10:08 0000 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. wschlich@gentoo.org 2004-10-29 10:41:22 0000 lostlogic, will you do something about it? if not, would you want _me_ to do something about it? :) motaboy@gentoo.org 2004-10-30 08:51:32 0000 *** Bug 69504 has been marked as a duplicate of this bug. *** caleb@gentoo.org 2004-11-08 11:52:44 0000 *** Bug 70490 has been marked as a duplicate of this bug. *** carlo@gentoo.org 2004-11-17 06:33:55 0000 *** Bug 71518 has been marked as a duplicate of this bug. *** wschlich@gentoo.org 2005-01-21 00:55:24 0000 *push* any news here? carlo@gentoo.org 2005-02-05 07:44:47 0000 *** Bug 80859 has been marked as a duplicate of this bug. *** carlo@gentoo.org 2005-02-15 10:00:48 0000 *** Bug 82130 has been marked as a duplicate of this bug. *** greg_g@gentoo.org 2005-04-20 14:28:21 0000 *** Bug 89854 has been marked as a duplicate of this bug. *** chris@realcomputerguy.com 2005-04-20 16:09:37 0000 *** Bug 89854 has been marked as a duplicate of this bug. *** abatko@cs.mcgill.ca 2005-05-11 11:08:54 0000 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 gentoo@nephros.org 2005-05-11 15:01:44 0000 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. askwar@digitalprojects.com 2005-05-24 09:21:46 0000 (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. gentoo@nephros.org 2005-05-24 10:41:18 0000 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.) askwar@digitalprojects.com 2005-05-24 14:23:24 0000 (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. carlo@gentoo.org 2005-05-30 06:05:05 0000 *** Bug 94481 has been marked as a duplicate of this bug. *** greg_g@gentoo.org 2005-05-30 06:24:23 0000 Reassigning to base-system. vapier@gentoo.org 2005-05-30 16:52:04 0000 base system does not maintain tar nor do we care about it jakub@gentoo.org 2005-05-31 02:43:43 0000 (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> vapier@gentoo.org 2005-05-31 05:25:36 0000 typo on my part ... i meant 'star' not 'tar' base system does not maintain star nor does it care about it jakub@gentoo.org 2005-05-31 12:40:38 0000 (In reply to comment #29) > typo on my part ... i meant 'star' not 'tar' Oh, I see. :-) Well, this package needs maintainer. vapier@gentoo.org 2005-06-09 17:56:14 0000 *** Bug 95618 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2005-06-12 03:55:48 0000 Unsolved for 1 1/2 years, no maintainer and still causing just troubles. What about hard-masking this? :/ slarti@gentoo.org 2005-06-16 10:42:52 0000 Fixed in CVS, thanks. jakub@gentoo.org 2005-06-16 14:36:53 0000 *** Bug 96298 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2005-06-16 14:38:01 0000 Still breaks kdevelop, even with star-1.5_alpha50.ebuild. :-( sguarin@fi.uba.ar 2005-06-17 06:50:31 0000 Created an attachment (id=61388) Reposting foo patch that excludes gnutar being merged sguarin@fi.uba.ar 2005-06-17 06:51:24 0000 Created an attachment (id=61389) Reposting ebuild using patch slarti@gentoo.org 2005-06-21 03:22:19 0000 This should be fixed in -r1. Thanks a lot. jakub@gentoo.org 2006-03-22 09:39:51 0000 *** Bug 127196 has been marked as a duplicate of this bug. *** 61388 2005-06-17 06:50 0000 Reposting foo patch that excludes gnutar being merged star-1.5_alpha46-gentoo.patch text/plain LS0tIHN0YXItMS41L01ha2VmaWxlCTIwMDMtMDktMTkgMjI6MDU6NTkuMDAwMDAwMDAwIC0wMzAw CisrKyBzdGFyLTEuNS1nZW50b28vTWFrZWZpbGUJMjAwNS0wNi0xNiAxNjozMTo1NS4wMDAwMDAw MDAgLTAzMDAKQEAgLTgsNyArOCw3IEBAIGluY2x1ZGUJCSQoU1JDUk9PVCkvJChSVUxFU0RJUikv cnVsZXMudG8KIAogI2luY2x1ZGUJCVRhcmdldGRpcnMuJChNX0FSQ0gpCiAKLURJUlM9CWNvbmYg aW5jIGxpYiBsaWJkZWZsdCBsaWJybXQgc3RhciBzcGF4IHN1bnRhciBnbnV0YXIgc2NwaW8gbXQg cm10IHRhcnRlc3QgbWFuCitESVJTPQljb25mIGluYyBsaWIgbGliZGVmbHQgbGlicm10IHN0YXIg c3BheCBzdW50YXIgc2NwaW8gbXQgcm10IHRhcnRlc3QgbWFuCiAKICMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IwogIyBEdWUgdG8gYSBidWcgaW4gU3VuUFJPIG1ha2Ugd2UgbmVlZCBzcGVjaWFsIHJ1bGVzIGZv ciB0aGUgcm9vdCBtYWtlZmlsZQo= 61389 2005-06-17 06:51 0000 Reposting ebuild using patch star-1.5_alpha46-r1.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA1IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L2FwcC1hcmNoL3N0YXIvc3Rhci0xLjVfYWxwaGE0 Ni5lYnVpbGQsdiAxLjEwIDIwMDUvMDQvMTQgMDM6MDM6NDIgdGdhbGwgRXhwICQKCmluaGVyaXQg ZXV0aWxzCgpTPSR7V09SS0RJUn0vJHtQL19hbHBoYVswLTldWzAtOV19CgpERVNDUklQVElPTj0i QW4gZW5oYW5jZWQgKHdvcmxkJ3MgZmFzdGVzdCkgdGFyLCBhcyB3ZWxsIGFzIGVuaGFuY2VkIG10 L3JtdCIKSE9NRVBBR0U9Imh0dHA6Ly93d3cuZm9rdXMuZ21kLmRlL3Jlc2VhcmNoL2NjL2dsb25l L2VtcGxveWVlcy9qb2VyZy5zY2hpbGxpbmcvcHJpdmF0ZS9zdGFyLmh0bWwiCiNUaGlzIFVSSSBm b3IgYWxwaGEgdmVyc2lvbnMKU1JDX1VSST0iZnRwOi8vZnRwLmJlcmxpb3MuZGUvcHViLyR7UE59 L2FscGhhLyR7UE59LSR7UFYvX2FscGhhL2F9LnRhci5iejIiCiNUaGlzIFVSSSBmb3Igbm9uLWFs cGhhIHZlcnNpb25zCiNTUkNfVVJJPSJmdHA6Ly9mdHAuYmVybGlvcy5kZS9wdWIvJHtQTn0vJHtQ fS50YXIuYnoyIgoKTElDRU5TRT0iR1BMLTIiClNMT1Q9IjAiCktFWVdPUkRTPSJ4ODYgcHBjIHNw YXJjIH5taXBzIGFscGhhIGhwcGEgYW1kNjQgaWE2NCB+cHBjNjQiCklVU0U9IiIKCkRFUEVORD0i dmlydHVhbC9saWJjIgoKc3JjX3VucGFjaygpIHsKCXVucGFjayAke0F9CgljZCAke1N9CgllcGF0 Y2ggJHtGSUxFU0RJUn0vJHtQfS1nZW50b28ucGF0Y2gKCWNkICR7U30vREVGQVVMVFMKCXNlZCAt aSBcCgkJLWUgJ3M6L29wdC9zY2hpbHk6L3VzcjpnJyBcCgkJLWUgJ3M6YmluOnJvb3Q6ZycgXAoJ CS1lICdzOi91c3Ivc3JjL2xpbnV4L2luY2x1ZGU6L3Vzci9pbmNsdWRlOicgXAoJCURlZmF1bHRz LmxpbnV4CgoJaWYgWyAiJHtBUkNIfSIgPSAiYW1kNjQiIF0KCXRoZW4KCQljZCAke1N9L1JVTEVT CgkJY3AgaTM4Ni1saW51eC1jYy5ydWwgeDg2XzY0LWxpbnV4LWNjLnJ1bAoJCWNwIGkzODYtbGlu dXgtZ2NjLnJ1bCB4ODZfNjQtbGludXgtZ2NjLnJ1bAoJZmkKCWlmIFsgIiR7QVJDSH0iID0gInBw YzY0IiBdCgl0aGVuCgkJY2QgJHtTfS9SVUxFUwoJCWNwIHBwYy1saW51eC1jYy5ydWwgcHBjNjQt bGludXgtY2MucnVsCgkJY3AgcHBjLWxpbnV4LWdjYy5ydWwgcHBjNjQtbGludXgtZ2NjLnJ1bAoJ ZmkKCn0KCnNyY19jb21waWxlKCkgewoJZW1ha2UgQ09QVFg9IiR7Q0ZMQUdTfSIgfHwgZGllCn0K CnNyY19pbnN0YWxsKCkgewoJZWluc3RhbGwgSU5TX0JBU0U9JHtEfS91c3IgfHwgZGllCglpbnNp bnRvIC9ldGMvZGVmYXVsdAoJbmV3aW5zICR7U30vcm10L3JtdC5kZmwgcm10CgoJIyBpbnN0YWxs IG10IGFzIG10LnN0YXIgdG8gbm90IGNvbmZsaWN0IHdpdGggb3RoZXIgcGFja2FnZXMKCW12ICR7 RH0vdXNyL2Jpbi9tdCAke0R9L3Vzci9iaW4vbXQuc3RhcgoKCWRvZG9jIEJVSUxEIENoYW5nZWxv ZyBBTi0xLiogUkVBRE1FIFJFQURNRS4qIFBPUlRJTkcgVE9ETwoJcm0gJHtEfS91c3IvbWFuL21h bjEvbWF0Y2gqCglkb2RpciAvdXNyL3NoYXJlLwoJbXYgJHtEfS91c3IvbWFuLyAke0R9L3Vzci9z aGFyZQoJY2QgJHtEfS91c3IvYmluCglsbiAtcyBzdGFyIHVzdGFyCgljZCAke0R9L3Vzci9zYmlu CgltdiBybXQgcm10LnN0YXIKCWRvc3ltIHJtdC5zdGFyIC91c3Ivc2Jpbi9ybXQKCWRvc3ltIHJt dC4xLmd6IC91c3Ivc2hhcmUvbWFuL21hbjEvcm10LnN0YXIuMS5negp9Cg==