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

bugzilla-daemon at supercluster.org bugzilla-daemon at supercluster.org
Thu Jul 1 16:09:25 MDT 2010


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

--- Comment #14 from Michael Jennings <mej at lbl.gov> 2010-07-01 16:09:24 MDT ---
(In reply to comment #13)

> You don't know that. You have this "there is ONE proper way" mentality towards
> system administration.

No, I'm saying there is one proper way with respect to RPM.  There's a big
difference.  :-)  And as an RPM developer, I have a pretty good idea what I'm
talking about.

> I say that whoever is building the software knows best.

And >10 years of experience with RPM and RPM-based distributions tells me
otherwise.  Most users want things to Just Work(tm), and proper use of the
macros does that.

> "properly" according to your narrow definition of how things should work; is
> not always correct.

That's like saying that it's okay to build a part for a car and completely
ignore the type of connectors required to attach the part to the rest of the
car.  You're trying to create something for use with RPM while completely
ignoring the interface.

> So these same admins, the ones you characterized as barely understanding rpm,
> are now using --defines? 

Now you're mixing up my words.  The people I previously characterized as
"barely understanding RPM" are typical software authors who try to create their
own spec files.

Users who build RPM's and install them into /opt already know how to set up the
macros to facilitate that.  They have to; if they didn't, they couldn't build
arbitrary RPM's that install elsewhere.

And the users who don't know how to do that want their RPM's to just work,
which means going to the correct locations for RPM, not the defaults for GNU
autoconf.

> Actually, you have an extra step there. untar, run configured, and run 'make
> rpm'. Seems pretty simple.

Also non-standard and not as simple as:

wget http://www.clusterresources.com/downloads/torque/torque-2.4.8.tar.gz
rpmbuild -ta torque-2.4.8.tar.gz

Or, even better:

mzbuild http://www.clusterresources.com/downloads/torque/torque-2.4.8.tar.gz

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

Just out of curiosity, do you actually use RPM's in general, or of torque?  Are
you saying this because it's something you, personally, do on a regular basis,
or because that's your view of what the community of RPM users wants?

Most RPM users expect to have a workflow similar to what I've described.  I
think it's great that you provide a macro for the configure arguments, and it's
very easy for someone to supply those to rpmbuild.  I have no problem with
that, per se.  The problems arise from propagating ./configure arguments into
the built RPM's.  This is not typical, expected behavior, and is contrary to
best practices.

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

The same reply could've been made to your point, and we both know that's not
the point.  rpmbuild -ta would not work properly, even with _prefix defined
properly.

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

Your solution does fix the specific concerns I voiced with overriding the
macros, so thank you for that.

My goals when I originally wrote my torque spec file were:
  1.  Fix adherence to best practices and standards for RPM packaging.
  2.  Provide a working, functional torque out-of-the-box as soon as the RPM is
installed.
  3.  Use standard conditional build directives and parameters to allow
build-time customizations rather than non-standard macros.
  4.  Reduce the number of unnecessary subpackages by consolidating where it
makes sense and using existing RPM features (e.g., --excludedocs).

I think I've accomplished those goals pretty well.  If anyone with commit
access wants to take a look at the spec I supplied and maybe consider adopting
some of the other stuff in there, please feel free.  Otherwise, I'm okay to
agree to disagree and consider the issue closed.

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