[torquedev] [Bug 66] merge debian and ubuntu build changes into TORQUE

bugzilla-daemon at supercluster.org bugzilla-daemon at supercluster.org
Thu Jul 1 13:51:46 MDT 2010


http://www.clusterresources.com/bugzilla/show_bug.cgi?id=66

--- Comment #10 from Michael Jennings <mej at lbl.gov> 2010-07-01 13:51:46 MDT ---
(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.

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

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

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.

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

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.

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

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 mailing list