On Mon, Sep 12, 2016 at 08:19:19AM -0500, Dennis Gilmore wrote:
On Sunday, September 11, 2016 7:15:45 PM CDT Dominik
'Rathann' Mierzejewski
wrote:
> On Sunday, 11 September 2016 at 16:40, Richard W.M. Jones wrote:
> > I'd like to talk about the ground rules that Fedora/RISC-V should obey
> > for making '%ifarch riscv64'-specific changes to spec files in
dist-git.
> >
> > I'm aware that no one wants invasive changes to be made (least of all
> > me) for the sake of an architecture that isn't generally available and
> > isn't even a secondary arch.
>
> [...]
>
> > My aim, once we have a pure RPM-built "stage4", is to start auto-
> > building all @Core packages as they are built in Koji (either using
> > koji-shadow, or similar). Many packages will just work. For others
> > it'll be a matter of fixing something and sending it upstream. It's
> > the ones where we have to make changes to the spec file to get them to
> > build which concern me. Ideally, if the changes are non-invasive, we
> > could add them to Fedora which would reduce the differences between
> > Fedora/RISC-V and Fedora.
> >
> > The question is what things should we be doing or should we not be
> > doing, especially w.r.t Fedora spec files in dist-git?
>
> IMHO, if the change is self-contained, follows the conventions
> of neighbouring code and doesn't break anything else then just
> notify the maintainer, give them a day or two to respond (especially
> if it's the weekend) and just go ahead and commit. At least, that's
> what you can do with the packages where I'm the POC.
>
> If patching of the upstream code is required, then please add a
> reference to a ticket filed with upstream, per our Packaging Guidelines.
>
> Regards,
> Dominik
The one thing I would add is do not use %ifarch to selectively apply
patches. The existing guildelines should be followed. You really
need to get patches upstream and spec changes in, carrying forks of
packages is frought with pain and errors. it was done for some time
on arm initially and it took a long time to fix things and get it
right.
No argument with that.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v