Dagmar d'Surreal no.spam at
Sun Jan 12 20:32:31 PST 2003

On Sat, 2003-01-11 at 20:38, Greg Schafer wrote:
> On Sat, Jan 11, 2003 at 05:07:25PM -0600, Dagmar d'Surreal wrote:
> > On Fri, 2003-01-10 at 13:21, Matthew Reppert wrote:
> > > Hi,
> > > 
> > > Is there a reason we don't use the H. J. Lu binutils releases in the book?
> > > I know that (at least) Debian and SuSE use them (but am told that really
> > > all
> > > major distributions do),
> > 
> > There's really not much more I can say about this other than it's
> > wrong.  Usually these wound up getting used in the past because they had
> > patches to fix issues the distribution developers were aware of, but not
> > because they were automatically better or something.  They are still
> > beta releases, and beta releases are definitely fast-moving targets.
> Sorry, but I disagree.

Why?  Not all major distributions use the HJ releases, although Debian
and SuSe are currently using them.  In the past almost all of the
distros have done a release using either the HJ Lu variant *or* the GNU
version depending entirely on which one contained the most
enhancements/bugfixes they felt were needed.  

> HJ's binutils releases have become the defacto stable release for Linux
> distros. Don't let the 90 in the version string fool you. Sure, the code
> might be a little less tested, but this is due to the fact that HJ's
> releases more closely follow the CVS head.

Personally I feel that less tested == less safe, unless there's some
important bugfix that makes the devil you do know more dangerous than
the devil you don't know.  This is the number one reason I go with the
GNU public release version unless I have a specific reason to think it's
broken--and at the moment I know of no compelling reason to prefer the
.90.0.x release over the .2.1 release.  Distros can afford to pick a
beta package and make it part of their software base, because it's a
known value for them, and if it appears to work with that particular
collection of binaries they've built, then it's as good as most of them
fee it needs to be.  If a problem develops, they have the resources to
troubleshoot and debug and double-check to release an upgraded package
if they need to.  IMHO, individuals have to be pickier and more
cautious, because they have actual work to do and can't typically afford
to spend as many man-hours (not to mention the average sysadmin doesn't
have the expertise to do so, let alone newbies) trying to troubleshoot
deeply buried assembly and compiler problems.  They need things to work
and not screw up more than they need things to work and be elegant.

In short, my experience leads me to believe the releases on are
the "safe" ones to use, and are easier to support.  If someone actually
discovers a bug that they need to get around ASAP, they can always be
told to use the fixed 90 release until the fix they need makes it way
back into the next public release.

> HJ clearly states that his releases are for Linux only. If you wanted to
> install the GNU binutils on your Solaris, Irix, HPUX or whatever box then
> you would definitely install the latest FSF release and not HJ's.
> Let me summarise it this way:-
> FSF Release:
>   - Supports more OS's
>   - Latest code from the stable branch of CVS
>   - Not always up-to-date WRT to latest kernel,gcc,glibc subtleties

Does this branch _not_ get HJ Lu's Linux changes piped back into it?  I
was under the impression that it did.

> HJ Release:
>   - For Linux only
>   - More closely follows CVS head
>   - Contains the latest subtle bug fixes 
>   - Usually has latest fixes for non-x86 arches
>   - A new release every time a significant bug that affects Linux is fixed
>   - Possibly less stable due to newer code
>   - Sometimes there is breakage when upgrading to a HJ release immediately
>     after release so usually best to wait a week for the dust to settle

...and here you forgot
    -  Is a _beta_ release.

>From release.binutils-

"This is the beta release of binutils for Linux, which is
based on binutils 2002 1126 in CVS on plus various

No matter what else may be said about it, it's still a beta release and
as such any changes have typically not been as thoroughly tested as a
public release.

> > >  and IIRC Alan Cox mentioned on lkml that they have
> > > some subtle fixes for Linux on various archs. The Changelogs mention mips
> > > and alpha in this respect. They also seem to be preferred according to the
> > > kernel documentation (Documentation/Changes mentions that you need
> > > or greater).
> > > 
> > > The current version is ...
> > >
> > > (where XX is your country code)
> > 
> > Anything with a "90" in it can not automatically be assumed to be newer
> > than what you might expect.  Always, always, check the timestamps in the
> > ChangeLog against the latest non-beta release to figure out which is
> > newer, but usually the beta releases don't take an incredibly long time
> > to go back into being put on
> > 
> > Please search the archives and you'll see where I've explained this in
> > detail recently, but suffice it to say that is actually
> > _older_ than the version found on
> That is simply misleading. The timestamp may be older but see above re which
> branch of CVS the code comes from. Please get your facts straight.

I'm not making this assertion based merely on the timestamps of the
files--I'm making it based on the content of the Changelog files in
them.  Unloss the ChangeLogs are being improperly maintained in the 90
release in question, there's not even a whole lot of difference between
them at the moment.  In any case, they both _far_ exceed the minimum
requirement of version

> FWIW, I have been using HJ's releases on my own systems for the past few
> months without problem.

I've used them a few times myself when I've needed to (particularly when
I had some SGI boxes I had to maintain).  They're usually just fine, but
the release rate for new versions (and to a lesser degree, the mortality
rate) is a lot higher than for the official release versions on,
meaning it's just that much more time you have to spend upgrading to
stay entirely current, and that much more attention that needs to be
expended to decide whether or not the new version contains fixes that
apply to your own system.  (On a side note, use of the HJ Lu releases
_would_ qualify as "bleeding edge")

HJ is very good about making sure bugs don't make it out the door, but
when problems with the package can cause such unbelievably obscure and
hard to trace problems, I greatly appreciate knowing that even more
eyeballs have been applied before the code became part of the GNU

> The fact remains that most of the major distros use the HJ releases. I try
> to monitor Redhat, Debian and Gentoo and I can certainly confirm that at
> least those guys use the HJ releases.

You say "most", he said "all".  *sigh*

> I'm starting to lean towards LFS using the HJ releases.

It's your call to make, but I think it would only be caving to "peer
pressure" from other distros at this particular point in the codebases.

That having been said, it wouldn't be terrible for the HJ releases to be
used in the CVS versions of the book when needed.

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list