New contributor - hello, and looking for sponsorship!

[Conrad Meyer]

On Saturday 25 October 2008 06:55:34 am Thorsten Leemhuis wrote:
> On 25.10.2008 15:21, Chris Nolan wrote:
> > Looking at packaging the RPM: the main thing that sticks out is that
> > there are two different source tarballs for 32 and 64 bit systems.
>
> Joy and fun with proprietary vendor drivers :-/
>
> > The
> > only difference between the two tarballs is the hybrid binary driver
> > itself - the rest of the source is the same. What would be the
> > recommended way to proceed with this type of scenario?
>
> Good question. I'm unsure myself.
>
> > I was wondering whether to include both binary files (they would need
> > renaming to distinguish which is which) within a new single tarball and
> > then use a patch for the Makefile to ensure it uses the correct binary
> > driver.
>
> Things like that makes it really hard for others to modify or update the
> package later -- every time I run into hacks like this while updating a
> package I'd like to cry. Hence I'd say: lat way lie dragons, don't go
> into that direction.
>
> > This seems a bit "hacky" so I wondered if anyone could think of
> > a more elegant solution?
>
> I'd download both tarballs and give them a x86-32 and x86-64 suffix.
> Then I'd include them as Source0 and Source1; in the spec use some
> ifarch trickery around the setup macro to extract the right one. Also
> not really nice (and it makes the SRPM a bit bigger), but it's a lot
> more clean afaics.
>
> But there are likely a few other more clean ways to solve the problem;
> maybe someone else on this list comes up with a better idea?
>
> CU
> knurd

This idea seems the best route to go to me (the "Fedora way" is to go with 
pristine source tarballs and patches / spec file changes to make it work, not 
to "fix" the tarball). It's also much less painful to do updates with.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>