tar/port extract problems on Jaguar (10.2.8)

[jeremyt@…]

I am receiving the same error as those with similar subjects. I've updated darwinports and see the change to portextract.tcl where autoconf is used instead of --no-same-owner but I am still receiving the same error (below) as reported before the change. Any suggestions?

Jeremy (Mac newbie)

---

Error: Target com.apple.extract returned: shell command "cd "/usr/src/darwinports/dports/www/lynx/work" && /usr/bin/bzip2 - dc /opt/local/var/db/dports/distfiles/lynx/lynx2.8.5.tar.bz2 | gnutar --no- same-owner -xf -" returned error 2 Command output: gnutar: unrecognized option `--no-same-owner' Try `gnutar --help' for more information.

bzip2: I/O or other error, bailing out. Possible reason follows. bzip2: Broken pipe

Input file

/opt/local/var/db/dports/distfiles/lynx/lynx2.8.5.tar.bz2, output file

(stdout)

---

[jmpp@…]

You updated your darwinports cvs checkout, alright, but did you rebuild the tools and reinstall them? If you did then I don't really see how this could still be affecting you, unless the configuration script is funky. Try reinstalling the tools and give it another try.

-jmpp

[jeremyt@…]

I followed the instructions for updating DarwinPorts at ​http://darwinports.opendarwin.org/docs/ch01s03.html prior to getting this error and I just tried it again with no luck. If this is not what you are referring to please let me know.

Oddly enough, if I run the command "cd "/usr/src/darwinports/dports/www/lynx/work" && /usr/bin/bzip2 - dc /opt/local/var/db/dports/distfiles/lynx/lynx2.8.5.tar.bz2 | gnutar --no- same-owner -xf -" from the command line it executes without any errors.

Any ideas?

Jeremy

[danielluke (Daniel J. Luke)]

Perhaps it's a $PATH issue?

ie. run which gnutar ...

The configure script could be finding a newer gnutar (that supports --no-same-owner) but darwinports is trying to execute an older version (that doesn't support it).

[jeremyt@…]

which gnutar returns /sw/bin/gnutar.

I did a search and found

/usr/bin/gnutar /opt/local/var/db/dports/distfiles/gnutar /usr/src/darwinports/dports/archivers/gnutar

Which one does darwinports use? There is a version difference between /usr/bin and /sw/bin. To correct this would I overwrite the older versions, use soft links or something else? Thanks for the assistance.

Jeremy

[danielluke (Daniel J. Luke)]

That would be the problem then.

dp's configure script found the newer gnutar (from fink?) and so set itself to use the --no-same-owner syntax.

You can fix your problem right now by changing your $PATH to not include /sw (or moving aside the newer gnutar) and re-installing darwinports base (re-run configure, make, and make install) so that configure doesn't see the 'wrong' gnutar.

I'll attach a patch to this bug to fix this 'right' (by limiting where configure searches for tar/gnutar).

[danielluke (Daniel J. Luke)]

Force a limited $PATH for tar/gnutar search

[jberry@…]

Hey Daniel,

I think this still isn't quite right. It's okay to limit the path we look in (I suppose, but this is a slippery slope--see below), but we should also be saving the entire path to the command, found using AC_PATH_PROG, rather than AC_CHECK_PROG, so that we don't run afoul of path during execution.

The problem I see (at least for purposes of discussion) with limiting the paths we search is that if we take the attitude of protecting the user during configuration against having installed other external software, then we shouldn't stop at tar, but move on to curl, and rsync, and cvs, and... And once we do this we've limited the user's configuration options.

Thoughts?

[danielluke (Daniel J. Luke)]

James,

You're probably right.

... but AC_PATH_PROG with a limited path might be the best option for preventing user problems (as most users aren't going to modify the path that port searches for executables and we could just search that path)... right?

... we could probably also allow an override (--with-my-own-strange-tar=/path/to/dumb/tar) if we need to not limit users' configure options.

(do you want me to learn more autoconf foo and submit a new patch?)

[jberry@…]

Daniel,

Actually, I think we're making this out to be too hard. The problem here is that the tar cmd detected at autoconf time (and which we checked for --no-same-owner) wasn't the same cmd used during execution. If has nothing to do with where that command was. So if we just remember, and use, the path of the tar cmd we decided on at configurate time, we should be fine.

Right? I'll patch it.

-jdb

[jberry@…]

Jeremy & Daniel,

I put a patch for this in cvs. It just remembers the tar path to use at runtime. Will you verify please?

-jdb

[jmpp@…]

(In reply to comment #10)

Jeremy & Daniel,

I put a patch for this in cvs. It just remembers the tar path to use at runtime. Will you verify please?

-jdb

Just to make things clear, the patch was put in CVS HEAD, i.e. not in the release1 branch nor in DP 1.0. Soon enough we're gonna have to start talking about bug fixes to 1.0, merging release1 with HEAD... that type of stuff. I'll take it on with portmgr@

-jmpp

[danielluke (Daniel J. Luke)]

(In reply to comment #9)

Actually, I think we're making this out to be too hard. The problem here is that the tar cmd detected

at

autoconf time (and which we checked for --no-same-owner) wasn't the same cmd used during

execution.

could the configure script mistakenly pick up a tar that is installed by dports now? That could create issues when doing port upgrades (or if the user removes tar).

I think we need to do a limited directory search (and if necessary allow user-override) along with using the full path to tar to have this fixed 'right'.

[jberry@…]

(In reply to comment #12)

could the configure script mistakenly pick up a tar that is installed by dports now? That could create issues when doing port upgrades (or if the user removes tar).

I think we need to do a limited directory search (and if necessary allow user-override) along with

using

the full path to tar to have this fixed 'right'.

Code to prevent detection at autoconf time of software installed via DP is handled by OD_PATH_SCAN in aclocal. This rewrites PATH to excise ${prefix}/bin and ${prefix}/sbin.

So this should already be handled.