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>
> 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.
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.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
