Bug 431539 - rpm build errors, and bad spec file coding, and bad configure coding, mostly involving SELINUX
rpm build errors, and bad spec file coding, and bad configure coding, mostly ...
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-05 06:47 EST by JW
Modified: 2008-03-04 07:40 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-04 07:40:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2008-02-05 06:47:43 EST
Description of problem:
There are a number of problems with 'at' spec file and also configure.in

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Read at.spec
2. Read configure.in
Actual results:
1. Externally defined WITH_SELINUX will always be ignored (eg from
/etc/rpm/macros or from build command-line), unlike other variables like
WITH_PAM.  Why is the spec file coded to properly handle WITH_PAM but not
similarly for WITH_SELINUX? Is this simply a form of coersion, because that is
the only way to gain acceptance of SELINUX by the community?
2. Handling of --with-selinux in configure.in is coded so that absence of
--with-selinux does not work as expected.  What is the point of having options
like --with-selinux if it is just a no-op?

Expected results:
1. spec files should be written properly .. perhaps somebody from Redhat could
give high quality guidance here.
2. configure.in should be written properly. The handling of --with-FEATURE is
normally done properly except for when SELINUX is involved (for some mysterious
reason).  There are plenty of examples of proper FEATURE handling, so there is
no excuse for not getting simple things like this right ... unless one has
ulterior motives in trying to cripple peoples ability to disable the pointless
and hysterical/paranoid SELINUX feature.

Additional info:
Comment 1 Tomas Mraz 2008-02-05 07:05:52 EST
Disabling SELinux and supporting custom builds with random features
enabled/disabled is definitely not a priority. So feel free to provide patches
if you want this fixed.
Comment 2 JW 2008-02-05 07:48:36 EST
Random features?

If only the person who added the selinux stuff had just done it properly in the
first place then it would have saved everybody, especially myself, a lot of bother.

But why bother added options like --with-selinux which don't work? Shouldn't
adding those options (not working at that) be an even lower priority?

Also, I see this happening over and over again in nearly every package created
by RedHat employees. The same mistakes keep getting reproduced. Why not just do
it right all of the time?  I really is so very simple.  After all RedHat
invented rpm so surely they should be the best at getting rpms right?

Comment 3 Marcela Mašláňová 2008-02-05 10:11:39 EST
The fix of configure isn't visible fix for those who don't use selinux. If you
are so interested in clean code, then please attach the patch for review.
Comment 4 JW 2008-02-05 16:55:53 EST
I don't use selinux and the fix of configure is visible.

And don't get me wrong - I don't like clean code either!

Comment 5 Marcela Mašláňová 2008-03-04 07:40:48 EST
I'm really appreciating your concern is the base packages, but I definitely
won't rewrite whole configure and Makefile according to new auto tools. 

It could be closed as WONTFIX or UPSTREAM.

Note You need to log in before you can comment on or make changes to this bug.