Opened 20 years ago

Closed 19 years ago

#922 closed defect (fixed)

book doens't explain how to unpack a package

Reported by: tivarsson@… Owned by: lfs-book@…
Priority: lowest Milestone:
Component: Book Version: 5.1.1
Severity: normal Keywords:
Cc:

Description

In chapter 5, "Constructing a temporary system" and the "Introduction" part, the 4th paragraph reads:

"Before issuing the build instructions for a package, you are expected to have already unpacked it (explained shortly) as user lfs, and to have performed a cd into the created directory. The build instructions assume that you are using the bash shell."

How to unpack a package is never "explained shortly". While not being a biggie, since most people doing LFS probably know how to unpack, the tar options can be somewhat tricky. I think you should add ("explain shortly") an example where you "tar xvjf <package_name.tar.bz2>" to show the user how to do it. Maybe even have that instruction (and the cd part again) for the first package and reiterate that this is expected for every package.

Change History (2)

comment:1 by Lamandriel@…, 20 years ago

I think you should add ("explain shortly") an example where you "tar xvjf

<package_name.tar.bz2>" to show the user how to do it.

I disagree for two reasons.

The first one being that LFS's intended audience (quote: "This book assumes that its reader has a good deal of knowledge about using and installing Linux software.") simply does not need this kind of information. They should know how to uncompress compressed files and how to extract files from an archive.

The second reason is even more important: the handling of compressed archive files is highly a matter of personal, standards writers' and distribution vendors' taste. I will try to make that clear by going through your suggestion from left to right:

  • *tar* xvjf <package_name.tar.bz2>:

In POSIX and SUS, tar was removed years ago and pax was added as a replacement. So, an operating system environment can be completely POSIX or SUS compliant and not even have a tar command any more. In that case, the correct line to use would probably something like 'bzip2 -dc <package_name.tar.bz2> | pax -r'.

  • tar xv*j*f <package_name.tar.bz2>:

In POSIX and SUS, tar doesn't handle compressed archives at all. And there's no reason why it should: one tool, one job. Tar is an archiver, its job is to archive/extract, not to compress/decompress. That's the job of a compressor/ decompressor. The Linux Standard Base adds the z option to tar for compression/ decompression of deflate (gzip) compressed archives, but doesn't have j either. Older versions of GNU tar also don't handle bzip2 compressed archives, there are different patches available which add that functionality, but not all of them use j as the command line switch, I seems to be another popular choice. S tar automatically detects compressed archives and decompresses them accordingly without having to specify j or z or Z at all.

  • tar xvj*f* <package_name.tar.bz2>:

S tar needs the following syntax: 'tar xf=<package_name.tar.bz2>'. Yes, that's violating POSIX, but there's not much LFS can do about that.

  • tar xvjf <package_name.*tar*.bz2>:

Here's another problem: which archive file format are we talking about, exactly? Ancient UNIX tar (tar), not so ancient but still pretty old UNIX tar (star), POSIX tar (ustar), Extended POSIX tar (xstar), xustar, exustar, suntar or gnutar? GNU tar cannot handle POSIX tar in all cases and many other tar implementations cannot handle gnutar. So, if the archives on the LFS package server are in gnutar format, then people would probably have to install GNU tar first. Does LFS want to explain that? We probably would have to tell folks to use 'gtar xvjf' instead to be sure to actually get the GNU implementation of tar, but on systems that have GNU tar as their "native" implementation, it might just be called "tar" and gtar might not even exist.

  • and the last one:

maybe, bzip2 isn't even installed on the system. Maybe, its functionality is provided by another tool. I think OpenBSD has a universal compress command that contains a BSD licensed reimplementation of not only the old UNIX compress command (producing the infamous .Z files) but also gzip (.gz) and bzip2 (.bz2). In that case, the pipe command would probably have to be 'compress -c <package_name.tar.bz2> | tar xf -'.

Conclusion:

The point I was trying to make (and probably failed to do so) is the following: explaining how to uncompress and extract compressed archive files is probably best left to the operating system environment's manual than to LFS.

comment:2 by jeremy@…, 19 years ago

Resolution: fixed
Status: newclosed

This one appears to have been fixed in testing at this point. It's no longer mentioned that unpacking an archive will be explained shortly after.

Note: See TracTickets for help on using tickets.