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 -
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
