Heads-up: brand new RPM version about to hit rawhide

[Panu Matilainen]

On Fri, 11 Jul 2008, Doug Ledford wrote:

> On Fri, 2008-07-11 at 19:22 +0300, Panu Matilainen wrote:
>>> Something like:
>>>
>>> SCMType: {cvs|svn|git|hg|etc.}
>>> SCMRepo: <repo_url, complete spec for SCMs like git, would be cvs_root
>>> for cvs>
>>> SCMModule: <module name for repo types that need this, such as cvs>
>>> SCMTag: <tag representing exact source matching binary package>
>>> SCMBranch: <branch on which tag exists, allowing the installation of
>>> later sources from the same product line branch instead of exact sources
>>> of the installed package at the user's option>
>>
>> Right, these are just regular spec/header tags, rpmdb itself knows
>> basically nothing about such things, it's all hidden inside headers which
>> are more or less just "blob of stuff" to the database. Yes, if it were
>> something like an SQL db, this would be a schema change, but not so in the
>> case of rpmdb.
>
> OK, so that makes things *much* simpler.
>
>> Adding new tags is no flag day at all. The only incompatible part about
>> such things is the spec syntax - any new tag there will mean older rpm's
>> can be used to build such a spec. Old rpm's can however handle the
>> resulting packages with new tags in the header just fine, assuming
>> existing tag types (things like "32 bit integer", "string", "string array"
>> etc) are used.
>
> I assume you meant to say older rpms can't build the new spec based
> packages, but older rpms can handle the resulting binary rpms just fine.
> Which is fantastic.

Yes, that's what I meant.

>
>>> Anyway, the above fields are the essential elements necessary in order
>>> to be able to support exploded source repos and usage of exploded source
>>> repos as canonical source versions of binary packages.  There's lots
>>> more you *could* do in rpm to make that support more integrated and
>>> nicer, but the rpmdb fields and spec fields are the absolute minimum.
>>> And, at least once those are in place, any additional support items can
>>> be added to rpm later at our convenience since everything beyond just
>>> the headers can be managed via scripts, macros, makefiles, build system
>>> changes, etc.
>>
>> Nod. This is post F10 material - just adding new tags is a total
>> no-brainer but *doing* something with them is an entirely different
>> question. I have all sorts of things in mind for enhancing rpmbuild and
>> integrating with SCM tools and such, but they'll have to wait until we get
>> this new release fully stabilized.
>>
>> I know. People have been waiting SO long for various things to happen in
>> RPM that everybody's out of patience and wants their stuff in NOW. Please
>> try to be patient a little bit longer: once this release stabilizes, RPM
>> can move to a "normal" development-release cycle where folks will not have
>> to wait 5+ years to get their changes in :)
>
> No offense, but as far as I'm concerned I'd trade your entire rpm update
> for the changes I listed above.  Nothing in the list of rpm changes I
> saw was so earth shattering that it even comes close to the reality of
> being able to use a sane SCM as a canoncial source repo IMO.  And people
> *have* been waiting *way* too long for this to happen...

Look, I know. It's just that there are like 50 similar "but we needed this 
two years ago" requests, they simply can't all happen at once no matter 
how much people yell at me. Package building is just one part of RPM 
functionality, the other parts have grave needs too.

> I was just sitting down to start working on writing the changes myself 
> (I hadn't gotten to figuring out how the spec fields were handled in the 
> rpmdb yet, but I had gone through the rpmbuild 
> -b?|-t?|--rebuild|--recompile as well as the rpm -i processes looking 
> for how to hook everything into the existing source code and what 
> changes to make, etc.) because it's something that's so overdue.  Now I 
> find out that even though I've gotten so fed up that I was willing to 
> put my own time in to make it happen (which is well out of my field as a 
> kernel developer) that it doesn't even matter if I'm willing to do so, 
> I'm blocked.  That sucks in ways I can't even describe.

If you feel like working on this, PLEASE do so! What I'm trying to say 
here is just that right now *my* priority number one is getting the new 
release stable so we have a place to put new developments into. The best 
way to accelerate introduction of something like this into rpm is to work 
on it, not getting angry at me ;)

 	- Panu -