[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging of the RISC-V ecosystem?

2016-11-13 18:15 Richard W.M. Jones:
I've led the packaging of Fedora on RISC-V
(https://fedoraproject.org/wiki/Architectures/RISC-V).  As of this
moment we have packaged 12939 source packages / 25769 binary
packages[*], which is about 2/3rds of Fedora.

If you have a problem with any package in Debian, then please take a
look at the corresponding SRPM
(https://fedorapeople.org/groups/risc-v/SRPMS/) to give you a clue
about what we did.  You can do:

 rpm2cpio foo.src.rpm | cpio -id

to unpack the sources.

Thanks Rich, and a pleasure to see you around here.

Sorry that we do not offer anything publicly yet in retribution to your
efforts, although actually most of the work has been untying dependency
cycles and stupid hacks, not much to actually use in other distros (with
your different package names, features/dependencies enabled, etc).

In particular I think using "rv64g" is a terrible idea because there
are going to be lots of extensions to this architecture in future, and
do you really want to have "rv64gc" "rv64gcabcdef" etc etc ad infinitum?

I think that I am more on your side of the argument, but earlier in the
thread Karsten was also worried about possible Debian derivatives like
Raspbian and using incompatible meanings for "riscv64" as it now happens
with "armhf" between Debian and Raspbian.  I am not sure if there are
similar problems with derivatives of Fedora.

If things come to be like this, I prefer that new derivatives (or ports
of derivatives) use strings which are different from whatever we end up
using, so using "rv64gc" would lead the way and imply that other ports
should use that scheme.

(But actually, it also just occured to me that this would not prevent
other ports from using different extensions with the same port name,
perhaps to create an "overlay" e.g. of multimedia packages optimised
with some instructions of multimedia extensions and different
dependencies, while keeping the architecture name for better
interoperate with our mirrors... similar to what happens with
"deb-multimedia" now).

Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>

Reply to: