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?
It has the virtue of not having to shoehorn things into the specfile
format and risk breaking backward compat.
thoughts?
-sv