[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


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

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


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

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