[Fedora-sparc] SPARC Status

Fabio M. Di Nitto fdinitto at redhat.com
Tue Sep 18 17:26:00 UTC 2012


On 09/17/2012 10:26 PM, Dennis Gilmore wrote:
> No one currently is working on Fedora SPARC, and hasnt been for quite
> some time. we would need to get gcc-4.7 bootstrapped as well as a few
> other bits and pieces. its work that I just do not have the time to do,
> I also do not have the interest that I used to have. I think its a bit
> of a disservice to say that Fedora SPARC is a secondary arch at this
> point. If people do not step up to get things fixed and working im
> planning to take down the SPARC koji instance and remove sparc support
> from fedora-packager.

Actually... rethinking a bit about this, there might be a way to save
the port.

Something I started pondering a while ago, but never got close enough to
do it.

The main issues with our port (beside too few people working on it) are:

- sparc64 userland

virtually we are the only distro shipping and porting to sparc64 and the
only reason we do it, is to build the kernel. IMHO.. a tad overkilling.
sparc userland can build sparc64 kernels.

- the current "base" is just too old and too complex to rebuild clean.

as you mentioned in another email exchange, the arm port, that was
recently bootstrapped, used a tool to generate correct dependency build
order when starting from scratch.

my suggestion would be to simply kill all we have now, kill sparc64 and
start clean.

Debian and other distros are shipping the same code base as we do (given
or taken) and they can keep up no problem because they don't have to
deal with all the 64 bit userland failures and upstreams are more
willing to take patches.

The approach i am suggesting here for bootstrapping is "scorched earth".

Get current sources, build in correct sequence -> save binaries
somewhere non-public -> clean chroots -> install chroots from first run
binaries -> rebuild all again -> publish new binaries, kill/destroy old
ones.

The reason to not make old ones publics is to make sure there is no
version/binary collision, there is somewhat value in keeping them
secrets and avoid destroying user souls ;)

Most of this can probably be scripted. Major work left (beside fixing
build failures) would be to fix kernel package and port anaconda
(already more reasonable amount of work).

What do you think?

Fabio


More information about the sparc mailing list