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 18:43 +0300, Panu Matilainen wrote:
>> On Fri, 11 Jul 2008, Doug Ledford wrote:
>>
>>> On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote:
>>>> At long last, we are about to get a brand new RPM version (alpha snapshot
>>>> at the moment) into rawhide. The list of changes from 4.4.2.x is massive
>>>> and a full summary needs a separate posting (will follow as time permits),
>>>> this is just a heads-up of immediate consequences for Fedora packagers and
>>>> rawhide consumers:
>>>
>>> [ snip ]
>>>
>>> This is great and all, but my first reaction was "Oh hell...what a
>>> colossal waste of time" referring to the fact that I've spent the last
>>> week or so pouring over rpm source code trying to see exactly what's
>>> needed to implement some things.
>>
>> You could've just asked :)
>
> Yeah, I know, I just didn't know a big update like this was in the
> works.
>
>>> So, that being said, if we are going to make this change in Fedora,
>>> especially one that involves all this "backup for rpmdb, rebuild your
>>> rpmdb, feed your rpmdb cake" stuff, can we make it a flag day and add a
>>> few new fields to the rpmdb schema and bump the rpmdb version?
>>
>> What schema? :) The rpmdb isn't exactly like your average SQL database...
>> What exactly do you want there?
>
> 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.

>> This is already a flag day of sorts, it's by far the biggest update to rpm
>> in several years. We don't need any more excitement right now, we want to
>> get a new non-4.4.x rpm in an settled. Then we can start looking at new
>> stuff again...
>
> Does "then looking at new stuff again" imply F10?  Or are you saying
> essentially table it until later?  And IMO it's always best to have only
> a single flag day if possible.  The additional rpmdb headers above (and
> subsequent new spec file tags to go along with them) are a flag day
> event.  Doing one flag day instead of two would be preferable IMO.

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.

> 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 :)

 	- Panu -