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