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 -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
