RPM problem: prereq: <file> not honored in upgrade ordering?

[Pekka Savola]

On 15 Oct 2003, Jef Spaleta wrote:
> Pekka Savola wrote:
> > Thanks for the rant.  Unfortunately, it is not relevant to this 
> > discussion, if you read the mail in detail.
> 
> Its relevant...to the bug summary you posted to bugzilla..which speaks
> about a 'reordering issue' where you didn't specify that you orginally
> saw the reordering issue with using autoupdate. Your bugzilla reports is
> quite misleading about the circumstances where you saw the 'reordering'
> issue...and makes it hard to actually try to verify...since you do not
> make mention of autoupdate in the bugzilla entry....full disclosure is
> important. You initial bugreport comment about a 'reordering' problem is
> misleading since you didn't specify the exact commandline you used when
> doing the 300 RPMs install...i'd hate for a developer to waste time
> trying to confirm a general 'reordering' problem wider in scope 

Right.  There seem to be two problems here, one with reordering using
hundreds of packages (not sure whether nodeps was used here), and the
second one which is easy to reproduce (without nodeps).  The end effects
seem to be the same.

I should have been clearer about separating these two issues.

Btw. I looked at rpm source and it looks like nodeps does not change the 
package ordering.  You have to use a separate toggle, --noorder, to do 
that.  So, if you are certain all of your deps are included. nodeps should 
not do harm (I would still not use it though).  Package upgrade with the 4 
RPMs with --nodeps *seems to* confirm this theory.

If jbj is listening, it would be nice to get an ACK/NACK on this..

> than a
> specific packaging problem with sendmail when 'reordering' bug was
> actually because autoupdate used --nodeps. This could easily a problem
> specific to the sendmail package...a packaging error with sendmail, and
> not a general problem with rpm itself. Have you checked to see if the
> other programs that use the alternatives system installs correctly..like
> the printing subsystems? If other alternatives based systems get
> installed correctly...

No, I haven't tested w/ CUPS + LPRng.  Maybe I will try at some point
soon.

> maybe its not a general rpm bug at all..and your
> bugreport is misfiled under rpm. Wouldn't you hate to waste the rpm
> developers time hunting down a general 'reordering' bug that doesn't
> actually exist...because you failed to tell them you were using
> autoupdate to do the large 300+ package install.
> 
> Now...that we are all pretty much convinced that a 'reordering' bug
> would be specific to autoupdate and not rpm...

I'm not sure we can ascertain that.  I doubt it very much.  But the recent 
autoupdate versions have eliminated all use of nodeps, and thus waste some 
CPU cycles in dependency resolution (when they've already been checked 
with rpm -U --test), so when/if I upgrade another box to RHL73, I might 
watch out how the reordering goes.  I certainly think this has nothing to 
do with nodeps, as nodeps is used only if all the external dependencies 
are met.

> we can handle the specific
> 'core problem' of why the postinstall scriptlet is not running
> alternatives like you expect.

Right.

> Have you tried running the alternatives command that is in the
> postinstall scriptlet by hand?
> /usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/sbin/sendmail.sendmail 90 --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail --slave /usr/bin/newaliases mta-newaliases /usr/bin/newaliases.sendmail --slave /usr/bin/rmail mta-rmail /usr/bin/rmail.sendmail --slave /usr/share/man/man1/mailq.1.gz mta-mailqman /usr/share/man/man1/mailq.sendmail.1.gz --slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /usr/share/man/man1/newaliases.sendmail.1.gz --slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /usr/share/man/man5/aliases.sendmail.5.gz --initscript sendmail
> 
> thats one very long commandline...it could be a simple syntax error in
> the command or something 

Right.. works from command-line, and works run non-interactively from a 
cronjob (as noted in the report).  The about only thing I can think of is 
that the command does not exist when it's being run... :-/

> and nothing to do with the order rpm is trying
> to install things (if used without --nodeps).

Doubtful.  This happens also without nodeps.

>  Can you get that
> alternatives --install .....
> command to work right after the rpms are installed?

Yep.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings