[torquedev] [Bug 66] merge debian and ubuntu build changes into TORQUE
bugzilla-daemon at supercluster.org
bugzilla-daemon at supercluster.org
Thu Jul 1 14:50:29 MDT 2010
--- Comment #13 from Garrick Staples <garrick at usc.edu> 2010-07-01 14:50:29 MDT ---
(In reply to comment #10)
> (In reply to comment #7)
> > But you don't know what the builder wants to do. It depends on the situation.
> No, it doesn't. That's what I'm trying very hard to explain. The macros are
> ALWAYS right because they comprise the configuration for RPM, and as the
> package manager, its configuration is authoritative. The builder wants the RPM
> they build to be properly installable on their system and/or the systems of
> others (which, due to the nature of RPM, must the similar). In order to
> accomplish this, the RPM configuration needs to be honored, not ignored.
You don't know that. You have this "there is ONE proper way" mentality towards
system administration. I say that whoever is building the software knows best.
> > Actually, -ta isn't ignored at all. I went through great effort to make sure
> > -ta works. Corner cases like 'make snap' took extra work.
> And yet, in reality, it does not work properly. I should be able to run
> rpmbuild -ta torque-2.4.8.tar.gz and get proper, working RPM's out the other
> side. The way it is now, assuming the RPM's build properly at all, the paths
> will be whatever the person who built the tarball last ran ./configure with
> (which may or may not be correct) rather than what RPM is configured to use via
> macros (which is ALWAYS correct).
"properly" according to your narrow definition of how things should work; is
not always correct.
> If someone building RPM's wants to put them in a different location, they
> expect to build able to use something like this:
> rpmbuild -ta --define '_prefix /opt/torque/2.4.8' torque-2.4.8.tar.gz
So these same admins, the ones you characterized as barely understanding rpm,
are now using --defines?
> and have it build and install properly into that path. Correctly-written spec
> files, such as the one I attached, do this. Incorrectly-written spec files,
> such as the one supplied with torque, do not.
> If I have to untar the tarball, run configure, and remake the tarball just to
> use rpmbuild -ta, the spec is wrong.
Actually, you have an extra step there. untar, run configured, and run 'make
rpm'. Seems pretty simple.
> > I have a solution. configure should still generate a torque.spec that exactly
> > matches what the user specified, but the torque.spec shipped with a distributed
> > tarball from Adaptive should have prefix=/usr.
> No, it shouldn't. configure should be used only to replace values in
> torque.spec.in which are immutable for a given tarball. In other words, I
> should be able to untar the tarball, run ./configure with ANY options I choose,
> run make dist, and get a tarball whose contents are IDENTICAL to the original
> tarball. That's the whole point.
I should be able to untar the tarball, run ./configure with ANY options I
choose, run make rpm, and get rpms that exactly match what I want.
We can't have both ways. You can't have something that customizes and stays
> The way things are being done right now is incorrect.
> > This could be done easily if whoever at Adaptive was preparing the tarball
> > (release or snapshot) always remembered to run './configure --prefix=/usr'
> > before 'make dist'. Unfortunately that won't work because he or she won't
> > remember to do it!
> And I thank you for proving my point. There is absolutely nothing stopping
> someone from Adaptive who has been doing some testing with ./configure
> --prefix=/home/foo/test/torque from running "make dist" and handing it off to
> an unsuspecting user or customer (or doing a release) and making the generation
> of RPM's from this release tarball impossible.
Not impossible at all. Just run ./configure again.
> > This solution must be automatic. configure must know when to write a
> > torque.spec with --prefix=/usr and when to do what the builder is doing.
> My solution *is* automatic. It defaults to the most correct option (using the
> macros RPM supplies for exactly this purpose) and still allows the builder to
> specify any values (s)he chooses by overriding the macros as shown above.
> There is NO CORRELATION WHATSOEVER between options passed to ./configure by
> someone building source and the paths into which an RPM should be installed.
> Again, someone who builds RPM's themselves will already have to have all the
> correct paths setup in their .rpmmacros or system-wide macros files.
> Overriding them in the spec file is NEVER correct and almost always causes more
> hassles for the person doing the building.
> > 1) configure looks for a .svn directory (if .svn exists, then --prefix=/usr is
> > written into the torque.spec).
> > 2) a pre-written buildutils/torque.spec.dist that only exists in the svn repo
> > is used in the tarball (copied to torque.spec before writing the tarball).
> > buildutils/torque.spec.dist would not, itself, be distributed.
> Either of these, based on the current spec file, will still be wrong. A
> correct spec file USES the macro values supplied by RPM; it does not replace
My solution is shipping a default torque.spec that uses the macros. This is
what you want and you are still fighting it? You are just arguing with me.
> As a customer, I am very curious to hear someone from Adaptive comment on
> whether or not they are willing to supply a correct spec file for their
> customers or if we will continue having to maintain our own independent spec.
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the torquedev