sparc64 built from jh branch

Dan Nicholson dbn.lists at
Fri Oct 12 06:30:11 PDT 2007

On 10/11/07, Jeremy Huntwork <jhuntwork at> wrote:
> Bruce Dubbs wrote:
> > Jeremy Huntwork wrote:
> >
> >> Anyway, that's it. All things considered, it's not that bad. Also,
> >> that's it for the hardware I have (currently) available to test with:
> >> x86, x86_64, sparc{,64}, and ppc.
> >
> > I think that's great, but I would not be in favor of putting Sparc stuff
> > into LFS.  The right place for that, IMO, is CLFS.
> Not trying to argue, however, the point of CLFS, strictly speaking, is
> cross-building.

Agreed. I don't think that's a valid argument.

The bigger issue I see is maintenance. I don't mind adding
architectures, but I think they need to be fully maintained. Like I
was saying recently[1], it needs to be either fully supported or not
supported at all, IMO. One of the benefits of LFS right now is that
you're nearly guaranteed to get a successful x86 build if there's no
operator error. The worst case would be if there was a known broken
path in the book.

What does that have to do with sparc64? You're the only person I know
that has one, so that means development and support is 100% you. And
the chances I get one are about the same as Richard moving back to
Texas :)

The other issue for me would be quality. If we're hacking every other
package to make it work on sparc64, that begins to degrade the book on
appearance. This is a much more minor point, but basically, I wouldn't
want the book to start to be littered by sparc64 specific fixes.

Having met those two conditions, I would be totally fine with putting
it in the book. Another alternative would be to maintain a branch
we're less supported (and possibly broken) arches were added. After
they proved mature enough, they could be added to the main book.



More information about the lfs-dev mailing list