[Rpm-maint] silly idea for srpms

[seth vidal]

On Thu, 2010-12-09 at 14:45 +0200, Panu Matilainen wrote:
> On Tue, 7 Dec 2010, seth vidal wrote:
> 
> > it'd be nice to have one of two things in rpm to do directly from the
> > python bindings. I've hacked around it - but it ain't pretty:
> >
> > 1. for a srpm to carry the specfile contents as an rpm tag that we can
> > get to just with rpm -qp --qf %{specfile}\n foo.rpm. So we don't have to
> > go through the trouble of cracking the rpm itself to get the specfile
> > out.
> >
> > 2. some way to extract the specfile from the srpm w/o having to go
> > through a subprocess call and/or other pain to rpm2cpio.
> >
> > Here's why - it would be handy for retrieving the spec file, passing it
> > to rpm.spec() to generate the list of binary pkgs that would be created
> > by this srpm being built.
> >
> > what would be the preferred route to doing that?
> >
> > the reason i suggested 1 is that would mean that pulling the rpm header
> > would give you that info and not require you to fetch all of the package
> > payload (which could be quite big)
> >
> > thoughts?
> 
> Something like this has come up before some time, somewhere.
> 
> There's no limit to how large a spec can be, but the header size is 
> limited. In practise though, any old spec fits inside the header quite 
> comfortably. It'd just mean duplicating the data "forever" to avoid 
> introducing a grave incompatibility in the src.rpm format.
> 
> However IMO the better question is: how to avoid having to go through srpm 
> at all? For many things, having the spec available separately in a 
> repository of some kind would be far more useful than dragging the oddball 
> noarch-but-still-arch srpm construct around.

srpm is the discrete blob we have on servers.

the simple use case is:

User wants to use repoquery to see the set of binary pkgs a srpm would
produce.

more advanced use case is:
Taking srpms and tsorting them for build order

-sv