[Rpm-maint] silly idea for srpms

[Panu Matilainen]

On Thu, 9 Dec 2010, seth vidal wrote:

> 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.

Yes, but it doesn't serve us very well.

> 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

I know there are plenty of use-cases for accessing the spec files. I'm 
just claiming we'd be better off with specs stored separately alongside 
the full src.rpm's somewhere in the (source) repositories, and teach the 
tools about them. Then you don't have to work around the annoyance that 
srpm is.

 	- Panu -