[Fedora-packaging] Arch-specific Requires

[Panu Matilainen]

On Fri, 9 Jul 2010, seth vidal wrote:

> On Thu, 2010-07-08 at 16:54 -0400, seth vidal wrote:
>> On Thu, 2010-07-08 at 10:20 +0300, Panu Matilainen wrote:
>>
>>> Actually fixing the issue is going to require more dramatic actions
>>> though and changes to the tools. All sorts of possibilities do exist, for
>>> example:
>>>
>>> 1) Forget SRPMs, just stuff the sources, patches and spec from a given CVS
>>>     tag into a %{name}-%{version}-%{release}.tar.gz tarball and distribute
>>>     those instead of SRPMs. There you have a format that's guaranteed to be
>>>     arch-independent all the way, and they're buildable too, just
>>>     'rpmbuild -tb <tarball>' and go.
>>>
>>> 2) Create metadata for the SRPMs per-arch, but only actually distribute
>>>     one SRPM. Might involve things like splitting header and payload to
>>>     separate files or something.
>>>
>>> ...or something.
>>>
>>> If you ask me, I would go for 1). Seriously. If you want metadata to go
>>> with the tarballs, strip the header out of src.rpm's on each arch and
>>> build per-arch metadata only.
>>>
>>
>>
>> Talking about 1 is probably worthwhile - hell - even just having the
>> Source locations need to be full paths would make it worthwhile.
>>
>> It might tie into some of the stuff that colin walters and I think
>> jkeating eventually want to do pretty well, too.
>>
>> definitely worth discussing.
>>
>
> Something to think about for the weekend:
>
> The rpm specfile language has long been a source of pain for both users
> of it and the rpm developers. Maybe the goal in #1 above is a
> jumping-off point to start away from the specfile language entirely?

Heh, I didn't have quite that far-reaching goals in mind wrt #1. I guess 
everybody agrees the spec "language" has ran wild a long time ago, but 
redesigning the "rpm build recipe" system is beyond the scope of this 
discussion. Thinking about spec file future belongs (and is perfectly 
welcome) to rpm-maint list.

The issue at hand is that although the SRPM largely looks and quacks like 
a duck, it's really a platypus, and the poor thing doesn't even know it.

What it's "good" for is recording information about the conditions in 
which a spec file was parsed in and package(s) generated. Ie when you run
     rpmbuild -ba [switches] <specfile>
and grab the results, you can then query the SRPM for various things like 
the build-requires effective for this particular build (subject to 
installed packages, effective macros, command line switches and all), on 
that architecture.

In the Red Hat Linux era, separate SRPMs were actually distributed for 
each arch, which is how SRPM "works". Back in those days the number of 
packages and architectures was quite something else and duplicating a few 
hundred megs worth of sources wasn't such a big deal. Doing that nowadays 
would be plain insane.

The SRPM is simply not a good format for what its currently used for 
(outside the buildsystem itself, where its usage for build-dependency 
installation is just fine). Sure its possible to write specs in a way that 
produce identical buildrequires and payload in all conditions, but it 
requires some care and packaging policies.

I've suggested getting rid of the distributed SRPMs completely, but 
apparently CVS + tags isn't sufficient from legal perspective. Well, from 
this POV: the spec/srpm combo CANNOT GUARANTEE a source rpm contains 
everything used to build the package on all architectures. Quite the 
contrary, its all too easy to create a spec which contains different 
sources and patches on different architectures. It's up to packager 
sanity + policies (assuming policies for this exist). The good ol' tarball 
created from CVS tags + lookaside cache at the time of build would have 
that guarantee, unconditionally. And a tarball is what it appears to be 
and not a platypus in disguise.

Oh and FWIW, this doesn't affect the way buildsys builds binaries a single 
bit, it "only" affects the source repository and anything using it. So 
while such a change would obviously require quite a lot of changes in 
various places, it doesn't require rewriting the entire buildsystem or 
disrupt the regular "do stuff in CVS, submit build, feed babies to 
rawhide" loop as such.

 	- Panu -