On Fri, 2008-07-11 at 20:12 +0300, Panu Matilainen wrote:
> On Fri, 11 Jul 2008, Doug Ledford wrote:
>
> > 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.
>
> Yes, that's what I meant.
>
> >
> >>> 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...
>
> Look, I know. It's just that there are like 50 similar "but we needed this
> two years ago" requests, they simply can't all happen at once no matter
> how much people yell at me. Package building is just one part of RPM
> functionality, the other parts have grave needs too.
>
> > 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.
>
> If you feel like working on this, PLEASE do so! What I'm trying to say
> here is just that right now *my* priority number one is getting the new
> release stable so we have a place to put new developments into. The best
> way to accelerate introduction of something like this into rpm is to work
> on it, not getting angry at me ;)
Maybe the difference between what you are trying to say and are saying
is the problem here.
You see, here's what I said (in a nutshell):
"We need these headers, everything else can wait, but just adding these
allows us to move forward in using exploded source repos. All the other
features a person might code into rpm can be added later because they
can be worked around in the meantime via scripts, makefiles, macros,
build system tweaks, etc."
You responded:
"Yeah, the headers are a no brainer - But doing something with them
takes some effort and I don't have the time plus I got these fancy
plans, so, umm, no...that'll have to wait until F11"
And my response was:
"Well, that's just fine...so I guess we can't make progress on things
because those of us that are here and willing to work on this aren't
allowed to."
And your response was:
"Hey, if you want to work on it, go ahead! Don't get mad at me."
So, my question is, which is it? Are you going to block things, or not.
I was angry because you said it would have to wait until F11 on the
grounds of your grand plans, while all I asked for was just the headers,
no more. You *assumed* I wanted you to implement some sort of full
featured support. As did Seth. People should what I wrote more closely
instead of letting their imaginations run wild. I asked for the bare
minimum. Now that we have that straightened out, let me rephrase the
question. Are the headers, and the headers alone, too much to ask for
in the context of F10?
--
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
