Bug 132045

OK, I added PreReq: httpd in -7.

Much kudos to you for finding this *before* FC3 final!

PreReq is dead.  Requires(pre) is still valid, but will probably not
do what you want.

Is this loop really necessary?  Does httpd really require httpd-suexec
or is it just someone's arbitrary judgment that they should be
installed together?  If they are truly inseparable, then why split the
-suexec package off?

If the two packages should be bundled together "most of the time" then
that is something that can be handled in comps rather than dependencies.

Mike, could you explain why PreReq does not solve this problem?  The
consensus on fedora-devel-list was that PreReq is sufficient to solve
the issue.   See #77972 for rational.  If it is still causing problems
the split can be reverted.

The problem is that having "PreReq: httpd" there means that you can't
remove the -suexec package which is the reason for splitting up in the
first place.

It *might* be possible to handle the "install -suexec when upgrade but
don't require it" problem if the original httpd package had 
"Provides: httpd-suexec = %{version}-%{release}" - in such cases I
*think* all the depsolvers will pull in the split-off package on
upgrade. Would need testing to be sure.

Erm .. never mind, the provides doesn't work either, even if there
were such a thing in the original httpd package (need more coffee
obviously).

Joe, I have been told by the rpm experts that PreReq no longer does
anything special.  It is the same as Requires.  It does not tell rpm
how to break loops.

If it makes sense to split -suexec off, then it should be possible to
do it in a way that avoids a loop.

I've looked at the rational (for the dependency) in bug#77972.  It
seems hackish.  The real solution is, as you say, to add the httpd
directive.  Since the current solution will not work, I suggest you
either a) revert the split, or b) drop the dependency.

If you keep the split it would be a good idea to add the user in the
subpackage's scripts as well, given the security implications of not
having the user around.

The consensus of fedora-devel-list was that the PreReq is correct. 
Can you ask your experts to participate in that discussion?

Ok, as of rpm >= 4.4, PreReq and Requires are equivalent; PreReq no longer has
the dependency loop breaking magic functionality it used to, which causes this
bug to resurface.  Just witnessed on a Rawhide box, from yum install output:

  [...]
  warning: group apache does not exist - using root
    Installing: httpd-suexec                 ####################### [ 6/10]
    Installing: httpd                        ####################### [ 7/10]
  [...]

After the transaction:

  $ ls -l /usr/sbin/suexec
  -r-s--x---  1 root root 11260 Mar 29 15:24 /usr/sbin/suexec

Side note: PreReq does seem to have some magic in it left after all, I could not
reproduce this with plain rpm CLI or yum localinstall.  But with yum install, I
can.  Pretty confusing...

(The info that Requires and PreReq are equivalent nowadays is from jbj.)

You beat to reopening this bug, as I had the exact same problem after "yum
install httpd" on a FC4 Test1 box I installed a few days ago, so I indeed
confirm that the bug is back.
Using yum, is package install ordering done within rpm (where some "leftover
magic" resides), or by yum itself? If the latter, then it may be at least partly
a yum bug.
But if Requires and PreReq are supposed to be the same, then either :
- httpd-suexec should Requires(pre): httpd
or
- http should have some virtual provide for the user it creates, and
httpd-suexec should depend on that

Maybe we could discuss on the fedora maintainers list the possibility of using a
specific namespace for provided/required users, something like "Provides:
user(apache)" or similar.

I'll change it to a Requires(pre) then, I suppose, rather than continue fighting
this.  Though I don't really understand:

- why PreReq semantics should ever change if RPM could just treat PreReq as
equivalent Requires(pre) and everything would Just Work rather than silently
breaking stuff

- why we need to hardcode usernames rather than uids in the RPM filelist since
the spec file hardcodes username apache as uid 48 in the first place.

Why do they need to exist in separate packages anyway?

See bug 131618 etc.

Changed to use Requires(pre) in 2.0.54-4, if it breaks again please scream at
someone else ;)

Well now I get:

# rpm -Fvh *-2.0.54-4.*
Preparing...                ########################################### [100%]
   1:httpd-suexec           ########################################### [ 20%]
error: %pre(httpd-2.0.54-4.i386) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping httpd-2.0.54-4
   2:httpd-devel            ########################################### [ 40%]
   3:httpd-manual           ########################################### [ 60%]
   4:mod_ssl                ########################################### [ 80%]
error: %post(mod_ssl-2.0.54-4.i386) scriptlet failed, exit status 255
error: %preun(httpd-2.0.53-6.i386) scriptlet failed, exit status 255

(with rpm-4.4.1-9)

this seems only to have made things worse for me.  Given the %pre script of
httpd is:

# Add the "apache" user
/usr/sbin/useradd -c "Apache" -u 48 \
        -s /sbin/nologin -r -d /var/www apache 2> /dev/null || :

which cannot fail, this is... odd.  Anyone have any idea what's going on?

The 255 error has probably nothing to do with the changed Requires(...). I
suspect SELinux issues or a broken interpreter. Was this a chroot-installation?
Else, some more '-vvvvvvv' might give more details about the error.

This was a normal Raw Hide install from a few days ago; let's see if it turns up
for anyone else.

httpd-2.0.54-3 and -suexec installed ok here using yum.  But bug 131618 has some
new suggestions.

Mmh, sorry about the noise, 2.0.54-3 < 2.0.54-4...

Paul said that PreReq had been restored to its previous behaviour in the Fedora
rpm package; so the change was probably unnecessary, but harmless anyway. 
Please reopen if there are problems, and I'll try and follow through on moving
the suexec stuff to a SELinux boolean.

-> bug 155716