If I try to install OpenOffice 3.* from the developers' builds' RPM's *converted* to TGZ (by rpm2tgz), the archives contain some files with fairly long paths.

The installpkg (and, possibly, updatepkg -- didn't try recently, so don't remember) *truncates* such paths at 80-something chars and *then* tries to install the result, effectively crippling the installation. Such truncation isn't reported by installpkg, AFAIK. I see that the installpkg utils are shell scripts, is there some shell limit in effect?

The example of truncated archive path follows (it's .xcu ini archive, but the .xc is actually installed):

opt/openoffice.org/basis3.0/share/registry/schema/org/openoffice/Office/UI/DbReportWindowState.xc

The RPM installation of original RPM's completes without errors. The Slackware is 12.1, with some additional pkgs.

Try using src2pkg to convert the rpm package instead of rpm2tgz.

No, no, the conversion itself works fine. I told you, I've checked the paths in TGZ archive.

It's the installpkg of this TGZ that produces an error.

The problem is most likely due to errors with tar-1.13. I observed the exact same problem with some large archives.

The tar here is GNU tar 1.16.1. Is this of any relevance?

Yes, installpkg and makepkg use tar-1.13.

I observed the exact same problem while trying to get src2pkg to use later versions of tar. The problem occurs because rpm2tgz uses the later version(1.16) to create the archive. But, installpkg uses tar-1.13 to unpack the archive. The two don't work well together.

Try using tar-1.13 to list the contents of the converted rpm and you'll see the diffference.

Again, I'll suggest that you use src2pkg to convert the rpm. It uses tar-1.13 throughout to insure consistency. I just converted an OO rpm using it to make sure and the files you indicate are correctly installed and named. The other option is for you to hand edit the rpm2targz program and make it call tar-1.13 instead of tar. Still, src2pkg will do a much better job of converting the rpms as it does lots of sanity checks and corrections if needed.

The difference between the tar versions boils down to this: tar-1.3 creates tar archives where each file/dir path is preceeded by './'. When tar-1.13 is used to unpack the archive, it strips off the first two chars of the file path. Later versions of tar have different behaviour, depending on the exact version. When archives created using later versions of tar are unpacked with tar-1.13 the path gets mangled. You can probably see more evidence of this by looking closely at the package database created in /var/log/packages when you installed the rpm2tgz-converted package -I would nearly bet that the first two chars of the paths are missing for the file listings.
Don't ask me why it's the *last* two chars which get stripped from the actual filename, It is because of the way that tar-1.13 counts the number of characters -since it intends to ignore the first two chars it gets the count wrong. In short, it'S not that the pathname gets limited to a certain number of chars -just that the last two don't get read.

You might want to report the bug to PatV -he can fix rpm2targz so that it uses tar-1.13, but it would be nice if you report your success with src2pkg if you use it... rpm2tgz is not really adequate for creating installable packages and should only be used to convert rpm *source* archives -I spent a lot of maddening days to figure out what was going on with this(and other) tar problems.

Thanks, I'll try to digest and try what you suggest.

As for the reporting to Pat -- where does one do that? This forum is linked from slackware.com -- is there any real issue tracker somewhere?