tar.gz to .tgz file?
 

Hi
Is there a simple way to convert a .tar.gz file to .tgz (I don't believe they are simply synonyms...or are they, in which case a simple rename will work)? Slackware is .tgz based and many packages come as .tar.gz.
I realize this might be a naive question ...

Thanks
George

There is no difference between a tar.gz and a tgz file. The tgz is like an abbreviation.

Yeah there is one way

mv file.tgz file.tar.gz

Sorry if I put it wrong.It means no diff betwen tgz and tar.gz


tar.gz is created when you gzip a tar file .
Ex: gzip a.tar
will create a.tar.gz

Cheers
Z

While .tgz and .tar.gz are both gzip compressed tarballs, you can't just rename any old .tar.gz file and expect to be able to use it as a Slackware package - its what is inside the file that counts.

If your package is coming as .tar.gz from the program author then it probably contains source code, not a Slackware package.

http://www.linuxpackages.net/howto.p...=Package+Howto looks like it will show you how to build a Slackware package from source code.

So now I am a bit confused. The fine print in S/Ware package management (below) says it uses .tgz files, and if - say - you only have .rpm files - it supplies a utility to convert from there called rpm2targz. There is another supplied utility called rpm2tgz, which does what the name suggests. It then goes on to say the "fiels are exactly the same", but some folks prefer one name over the other.
And I quote: "NOTE: Running rpm2targz will create a .tar.gz file, while running rpm2tgz will create a .tgz file. The files are exactly the same, the only difference is the extension format (some people prefer one over the other)."
http://www.slackware.org/config/packages.php

Now, the native pkgtool utility will take only .tgz as input (the command line commands such as upgradepkg...I am not sure..there one way to find out, of course...): so I'm afraid I still don't know
if they are interchangeable (and can be renamed), or are different. Perhaps this belongs on the "Distro"/Slackware Board?
Thanks
George

You're placing too much importance on the file extensions. In traditional UNIX parlance, the .tgz and .tar.gz file extensions both indicate exactly the same thing: a tar archive compressed using gzip. Which extension you use is typically a matter personal preference, so in that sense they're interchangable.

However, as dorward pointed out, .tgz and .tar.gz are generic extensions. Just because you see one of them does not imply that the file has anything at all to do with Slackware. A .tgz file could be a Slackware package, or it could be the collected works of Charlotte Bronte. Without more information than the extension, there's no way to know.

That said, Slackware packages use the naming convention name-version-arch-build.tgz, e.g zlib-1.2.2-i486-1.tgz. There are slight variations between packages, but in five years as a Slackware user, I have never once seen anyone distribute a Slackware package with a .tar.gz extension. If you have a .tar.gz file, the odds are that it's not a Slackware package.

Ada Hacker - you are exactly right. What I am dealing with is non-Slackware packages, in this case:
ActivePerl-5.8.0.802-i686-linux.tar.gz.
It does look a lot like the standard S/Ware naming convention, however, but it is definitely not from SLackware.
Thanks
George

Let me re-phrase this question. If I have a .taz.gz file which I know is an installable package (that is not source, and may or may not be "authenticated" by Slackware) can I simply rename it to .tgz to conform with Slackware package install fotmat requirements?

Additionally, Slackware offers an rpm conversion utility caled rpm2targz (which it claims is an identical structure to .tgz files). This makes me think they could only supply such a thing if their package installation can also handle files with that suffix (tar.gz), in addition to .tgz, else why supply it? However, I have found nothing to convince me of this line of thinking.
Thanks
George

No, no, and no. And just to be absolutely sure, I downloaded the Linux build of ActivePerl, looked at the contents, and I can tell you right off that simply changing the extension will definitely not work.

Here's the deal: Slackware packages are just gzipped tar archives, but they follow a particular format. For the package to work, the contents must contain a mirror of the desired file locations relative to root with an install directory that contains an optional post-install script and a package description. If you try to install a .tgz file that doesn't follow this format, it might "work" in the sense that you don't get any errors, but the "installation" will be broken. All the files will be in the wrong place and your system may get messed up.

I suggest you grab a nice, small package from your Slackware CDs (or an FTP server, or linuxpackages.net) and open it up to see what's inside. Just make a temporary directory, change to it, and run If you browse through the resulting directories, you'll see what I mean about the format. Now, if you try this with the ActivePerl archive, you'll see that the directory hierarchy is very different. That's why it won't work.

1) Again, you're placing too much importance on the file extension. As I explained above, it's the contents of the file that make it a Slackware package, not the extension.
2) One reason for using rpm2targz might be if you want to make changes to an RPM before you try to install it. For example, you might need to change some standard directories, modify the package description (I'm not certain if rpm2tgz even sets this), or add something to the install script. In those cases, giving the file a .tar.gz extension would keep you from confusing the converted file with a real, polished package.
3) rpm2tgz and rpm2targz are actually the exact same program. If you run you'll see that it's actually just a symlink to /usr/bin/rpm2targz. rpm2targz is just a shell script that converts the RPM into a gzipped tar archive. In fact, if you look at line 115 of rpm2targz, you'll see that if the script is invoked with the name 'rpm2tgz', then it will simply rename the file from a .tar.gz extension to a .tgz extension.

Ada Hacker - thank you. The Perl seemd to install quite nicely, as I recall, into an /opt/ sub-directory of his own choosing, as a result of a tar. (I had to compile and make the various database Interface modules, from source, which was fine). This installation is clearly unrelated to the original PERL that was packaged with S/Ware 9.1 (later on I figured out what I was doing, that I didn't need the ActivePerl DBI and DBD modulesm and could have left the original in place, but not to worry). What struck me as interesting is that prior to doing, this I uninstalled the original PERL with pkgtool; the evidence of same appears in /var/log/removed_packages ("lprng-3.8.22-i486-1
perl-5.8.0-i486-5"), but he didn't seem to remove the many files, from usr/local/ /bin, /man1 etc......
I really thought that a formal removepkg of a Slackware installed package would have removed the files.....

Regardless, many thanks for the more detailed explanation of SWare packaging. I have been struggling with this for some months now, installing an IBM product that is rpm-based (DB2 UDB RDMBS) into a distro that does not use rpm packages as its native format, which has created endless difficulties. Install scripts failed, and applying recommended "fixes" to the scripts to disable rpm-based dependency checking (--nodeps) also failed, with segm faults. It was then that I stumbled across "rpm2tgz", ran this on the hundreds of rpm packages, and was able to install with upgradepkg --new-install (or installkpkg, altho' I preferred the former). Perhaps it is partly for this reason, that IBM has only "validated" a handful of distros', speficically RHEL and SuSe. The rest are not - how shall we say - safe for Production. I mean, it's a free country, there is nothing to stop a guy/company, just don't expect IBM support, if you know what I mean. I am seeking to simulate a Corporate UDB/LINUX environment, and never realized I would encounter these roadblocks....So, this raises the question of further (validated) LINUX installations ....
http://www-306.ibm.com/software/data...inux/validate/
George

The easiest way I've found to make a Slack package fron source is Checkinstall. From source, you compile like you normally would, but instead of typing 'make install' you type 'checkinstall'.

The script will automatically generate a slackware package after asking you a few questions. The name of the package will follow the slackware standard, and it will even collect as much of the documentation as it can to put under /usr/doc

After the script is done, you have a package that you can install, or move to a different computer, or backup so that you don't have to compile that source package ever again for Slackware.

If you did a full install of Slack, it should be installed

There is no Diff between Tar.gz and TGZ ... just rename it

Thanks - you've just undermined the entire discussion of this thread. Did you even read it?

Now:
*.tar.gz and*.tgz are simply naming conventions. They are commonly also the same content, and are just two ways of indicating a gzipped tar file (thorugh .tar.gz is preferred). However, the typical usage is this:

*.tar.gz - commonly known as a "tarball". Is a GZipped *.tar file, and commonly used to store source code.

*.tgz - commonly known as a Slackpack. Is also a GZipped *.tar file, but the contents are binary - read not source code - and it also contains a script to be used by "installpkg", "removepkg" or "upgradepkg" to place the binary files where they need to go.

mdg - Thank you.
Are you saying that running checkinstall will "make known" the package to S/Ware, thereby enabling it (the newly compile module(s)) to then conform to its own native package mgmt facilities, and so, useable by pkgtool upgradepkg, removepkg etc., etc. And so, known "internally" to S/Ware, in the same manner as all other "native", or S/Ware supplied packages?
I didn't know this.
Thanks
George

Once you've compiled the package with checkinstall, it is a complete Slackware package in every respect. You'll be able to use all the native pkg tools on it.