[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]