[PATCH] Re: bzip2 1.0.2 issues
phil-lfs-dev at ipal.net
Sat Feb 9 05:50:50 PST 2002
On Thu, Feb 07, 2002 at 11:32:44PM +0000, Ken Moffat wrote:
| > The problem I had with bzip2 was that LFS had to "bend over backwards" to
| > deal with deficiencies in the bzip2 Makefile that simply got worse with
| > the 1.0.2 release. An alternative way to build is to just add on more
| > commands to the many LFS already gives. Most other packages are simple
| > to install, so why is bzip2 needing so many? I could have added those
| > extra commands as LFS style instructions, but instead, I decided to look
| > at it as a problem with bzip2, not a problem with LFS, and fix what I
| > could as close to the problem as I could. It's approximately what I
| > would do if had taken over maintainership of bzip2 (there's more, but the
| > real maintainer is headed that way anyway). Also, I was installing this
| > to Slackware machines and this was a single fix to the package to make
| > everything simpler.
| A fair point of view. My own gut *feeling* is that about half of the
| required packages have enough variations in the required instructions for me
| to forget trying to standardise the instructions before the LFS system
| itself is built.
I fully expect to have to deal with variations. It's just that bzip2's
variations are among just a few packages that I believe are excessive.
And I don't believe that's LFS's fault at all. LFS's goal isn't to go
back and fix packages, but just deal with however screwy it might be.
OTOH, I felt more freedom to "fix" the package to some extent.
I'll be quite happy to see A simple ste of just a small few instructions
for each package to be installed by LFS.
| > Putting things in /usr is the default. The SUPREFIX= in the instructions
| > is what changes it over to / for just a few things (bzip2, bunzip2, bzcat).
| Stylistically I haven't noticed any SUPREFIXes before, maybe my life has
| been too sheltered.
I separated certain installed components within the package which I believe
are useful in single user mode. Basically these are bzip2, bunzip2, and
bzcat. Of course being linked dynamically, the library is needed, too.
What I did was made a separate prefix setting name for these. I made it
default to the setting of the normal prefix, so the effect of not setting
any "SU" prefixes is as if I had never separated them in the first place.
Everything would be installed in /usr in that case (unless PREFIX= was set
to different). I simply put "SU" in front of the relevant names to make
the new names. It's a way to specify a different prefix for just the subset
if "useful in single user mode" components.
| > The patch was built with the command:
| > diff -u Makefile Makefile-shared-gnu-linux
| > The patch is supposed to be applied to "Makefile-shared-gnu-linux". Maybe
| > I should hack the patch to use "Makefile.old" instead of "Makefile" as the
| > old file. Maybe leaving out the "N" option will do it right.
| I thought patch always worked out the filenames it was going to patch for
| itself ? I've never yet given it a filename other than the name of the
It turns out patch is makes some kind of complex decision about which file
it applies the patch to. In many cases it is the new one. In others it is
the old one. My man page does not specify this very clearly, and has some
examples that strongly suggest only one way (and now seen to be in conflict
what actual behaviour). I'm still trying to get some "experts" to pin down
exactly what patch is supposed to do and in what circumstances.
Even I don't know everything :)
Certainly not the obscure undocumented[*] behviours that are rarely encountered.
[*] apparently it is documented in a pay-for POSIX document.
| > | I see the benefits of being able to do a straight `make' and `make
| > | install' in Ch06, but the instructions in the current book cut down a lot
| > | of cruft (`bzip2-shared' instead of three instances of `bzip2' which is
| > | still shared but about twice the size, and so on).
| > What cruft are you seeing from my Makefile?
| > Here's what I ended up with installed:
| > 43624 2002/02/06/061842 /bin/bzcat
| > 29768 2002/02/06/061845 /bin/bzip2
| You can symlink bzcat to bzip2, but if you don't they ought to be the same
| size (I guess this relates to the existing bug/feature where bzip-shared
| is built, *almost* as an aternative to normal building, using its own
| Makefile. Look at the existing bzip instructions in the book if you don't
| see what I mean.)
It would make sense that bzip2 (aka, bunzip2) and bzcat can be the same
executeable image. As for the size, it looks like by scripted stripping
logic missed bzcat. I probably assumed it was linked and didn't include
it in the script component for bzip2. They should just be linked, and I
personally prefer a hard link.
| > 9256 2002/02/06/061845 /bin/bzip2recover
| > 64877 2002/02/06/061842 /lib/libbz2.so.1.0.2
| > 1582 2002/02/06/061842 /usr/bin/bzgrep
| > 1582 2002/02/06/061842 /usr/bin/bzegrep
| > 1582 2002/02/06/061842 /usr/bin/bzfgrep
| three identical shell scripts. Ok, if your block size is 2048 bytes it
| doesn't make a lot of difference, but people using reiserfs could notice
| the difference if these were links.
The shell scripts can be linked, too. How does reiserfs behave regarding
this with symlinks vs. hard links?
| > | Ch06 using the patched makefile
| > | _______________________________
| > | Again cd ~/test; rm -r *
| > | bzcat ../bzip2-1.0.2-Makefile-shared-gnu-linux.patch.bz2 | patch -p0
| > | make
| > | make PREFIX=/home/ken/test install
| > |
| > | Results look the same, except that the shared library and its symlinks
| > | have been installed in lib/. This is what the book
| > | will do manually.
| > The default for PREFIX is /usr and the default for SUPREFIX is to use
| > whatever PREFIX has. So if you change PREFIX alone, you change it all.
| > If you want to have (like I do) most everything in /usr but the commands
| > that are useful in single user mode (and the library they need) in /
| > (e.g. /bin and /lib) then leave PREFIX=/usr (default) and set SUPREFIX=
| > (note: it is assigned the empty string) so a few things go in /bin and /lib.
| Note I didn't think I had a Makefile-shared-gnu-linux created as a result
| of this (because I'd forgotten what your original mail said), but
| something worked fine.
For Linux users who apply my patch when doing a shared/dynamic build, it
doesn't matter that patch applies to the wrong file. If it applies to
"Makefile" and you use that, you get a shared build. The difference in
names was intended for non-Linux systems (e.g. as part of the potential
to roll it back into the original package).
| > | cp Makefile Makefile-shared-gnu-linux (this seems excessive when you can just untar to restore the original)
| > | bzcat ../bzip2-1.0.2-Makefile-shared-gnu-linux.patch.bz2 | patch -p0
| > | (rearranged because the patch is actually bzipped)
| > | This patches Makefile, i.e. the original file, not the file with the new name
| > | make SUPREFIX= (no point using the unpatched Makefile)
| > | make SUPREFIX= PREFIX=~/test install : test fails at `cp -f bzip2 /bin/bzip2.tmp' in directory /bin
| > | (that seems acceptable, I don't want to overwrite my current executables, but it is perhaps slightly opaque : leave the
| > | identifier not set, and it knows to use /bin).
| > I don't know why patch is applying to the old file in this case,
| > but it does apply to new files in other places I'm using it. The
| > docs are not saying what cases would cause it to reverse the file
| > names (neither of us is using -R which is the only way I know for
| > it to reverse). Someone more familiar with the obscurities of the
| > patch program can perhaps tell me why this happens in some cases
| > and not most.
| I'll maybe take another look in a few days (I'm really trying to automate
| my LFS building at a moment, and I plan on watching a lot more TV now the
| olympics have arrived). I haven't looked in detail at using diff/patch to
| create new files, maybe I'm overlooking something. Alternatively, the
| testing was on a Mandrake 7.2 box (/home was 99% full on my LFS box),
| maybe there is something different in their patch (seems unlikely).
Linux users (any distro with shared library support) do not need the
original unpatched Makefile at all, so for them it is fine to apply the
patch to just "Makefile". The idea was that if this went into version
1.0.3 it would come out in the form NOT of a patch for Linux users to
apply, but as an alternate Makefile for Linux users to use (patch
already applied in the new tarball)
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ |
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev