[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, 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.

> > 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...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.

Doug Ledford <dledford redhat com>
              GPG KeyID: CFBFF194

Infiniband specific RPMs available at

Attachment: signature.asc
Description: This is a digitally signed message part

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