Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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. ***

*** 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 an attachment (id=61388) [details]
Reposting foo patch that excludes gnutar being merged

Created an attachment (id=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. ***