On 8/17/06, Monty Taylor <[EMAIL PROTECTED]> wrote:
Ahh... well that at least explains why everything is hardcoded.
In some ways it is actually done with variables (look at heartbeat.spec.in in CVS)... except that the variables are filled in by configure (when we ship it) instead of rpm (when you build it).
I suppose from the way you that was worded that no one is likely to discuss that process... dare I ask why it's done that way?
To be blunt, the answer is "because Alan wont allow it to be changed". It works for him so thats how it stays.
If it isn't up for debate, can I suggest not distributing the heartbeat.spec file at all, but instead only the heartbeat.spec.in, as there is no way for someone to know that the spec file is indended to only be generated from the packaging. Also... (ok, I guess I am arguing now. sorry, I know I'm new on the list) the source RPM does not work if you do things this way. The spec file distributed isn't flexible enough since it was generated from someone's ConfigureMe script. So where you think you could do a rpmbuild --rebuild heartbeat-2.0.7-1.src.rpm, you will be sorely disappointed on any 32-bit machine. I would argue that this is a broken SRPM. Configure should configure the software. An rpm spec file should run configure to configure the software based on the system-wide RPM settings. I'd be happy to work on (or help work on) a way to make a spec file that works out of the box, but also could still be used with the ConfigureMe workflow you are using now, if that's important. I'm sure it could be accomplished with some macros at the top of the spec.in. Oh, lest I be though completely rude, thanks for the fantastic software! I install and use it with new people every week, otherwise I wouldn't feel quite so strongly one way or the other. :) Even if it is unlikely to get applied - here's a version of the patch going the right way. Monty On 8/17/06, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > On 8/17/06, Monty Taylor <[EMAIL PROTECTED]> wrote: > > Hey all, > > > > I just realized that I may have replied to an old message and caused > > what I sent to get buried in the past of a threaded client. :) So here > > it is again... sorry for the repost if you had already seen it. I've > > been seeing discussion of spec file work, so I thought I'd jump and > > down a little before I have more merging work to do. > > > > I've been hacking on the spec file for a little while and figured I > > should maybe start sharing. I wind up building RPMs at client sites > > almost every week. (I know - I could just set up a repository - but > > where's the fun in that) > > > > I had a problem building on 32-bit installs, since the /usr/lib64 > > location is hardcoded in to several places. So I replaced most of the > > locations with location macros. The spec file I've been using is > > expecting redhat-rpm-config to be installed... which obviously won't > > be on SuSE, but I'm not sure what, if any equivilent package SuSE has. > > So I'd love feedback on that. (I tried to instal SuSE in a VMWare, but > > apparently doing an internet-basd single CD install isn't so easy with > > SuSE... so I'll do it later) There is still a bug I'm trying to track > > down where I don't think some of the files are being installed by make > > install into the build root, but are actually going into the normal > > tree. But I haven't found it yet. You only notice it the second time > > you try to build on a box. > > > > I also did some more magic with the snmp subagent and the mgmt client. > > They both now support a --with option to rpmbuild. So you can do > > rpmbuild --with snmp -ba heartbeat.spec. I defaulted snmp to on and > > mgmt to off, just because that's what works for me in most places. I > > did my best to make the prereqs and reqs change with that choice, > > although I haven't tested that 100% in a jail or anything. > > > > Some of the magic is still a little ugly. I think there are too many > > macros up there... not for functionality, but just stylistically, it > > looks really ugly. I'll try to clean that up some. But it works and > > has the intended behavior. > > > > I agree that the glib-devel and glib2-devel thing is odd - but I > > haven't tested that yet, either. It's on the list. > > > > I'd love feedback... this all works for me, but if there is a reason > > we don't want to do this, I'd love to understand it. > > > > AND - I just realized that I diffed in the wrong direction. :( I'll > > fix that in just a bit - I'm on the wrong machine ATM. > > Nod - took me a few minutes to figure that out. > Seemed like an odd patch otherwise... replacing variables with > hardcoded values :-) > > While I heartily agree with the patch in principle, the policy of the > project is to generate the .spec file with configure (which, um, then > calls configure - go figure). > > So your patch is unlikely to be applied I'm afraid :( > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ > > _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
