On Fri, Mar 11, 2005 at 02:15:18PM +0200, Ville Skyttä wrote:
> On Thu, 2005-03-10 at 16:06 -0500, Tim Powers wrote:
> > On Mar 10, 2005, at 3:56 PM, Nils Philippsen wrote:
> > <snip>
> > >
> > > Don't "PreReq:" (which gets treated like a simple "Requires:" IIRC),
>
> Almost. In case of circular dependencies, PreReq "wins" over Requires.
> In the vast majority of cases (ie. when there are no circular
> dependencies), they're equivalent, and rpm will do the right thing at
> install time.
No no no no no no no no!
There is literally no difference between PreReq: and Requires:, rpm-4.4
and beyond is incapable of either setting or testing RPMSENSE_PREREQ.
>From /usr/include/rpm/rpmlib.h:
RPMSENSE_ANY = 0,
...
/* bit 6 used to be RPMSENSE_PREREQ */
#define RPMSENSE_PREREQ RPMSENSE_ANY
Now please explain how rpmlib distingushes between PreReq: and Requires:
when the bit cannot be either tested or set because the mask is 0?
>
> AFAIK, erasure ordering is still unimplemented though, and the only
> thing a packager can do is to "manually" take that into account in
> specfiles where necessary.
>
Erasure ordering has always been implemented as the reverse of
install ordering., so "unimplemented" is more FUD.
> > > use
> > > "Requires(pre):" and for that matter "Requires(post):" as well. Don't
> > > do
> > > this:
> > >
> > > Requires(pre,post): /sbin/chkconfig
> > >
> > > but do that instead:
> > >
> > > Requires(pre): /sbin/chkconfig
> > > Requires(post): /sbin/chkconfig
> >
> > Every time I see this I get confused. jbj: please tell us whether or
> > not we should be doing this. I remember the stone-age when it was
> > introduced, abused, and we were told not to do this anymore. What's the
> > current recommendation?
>
I couldn't care less what you do as packagers, the syntax is there, and
you can use as you see fit. It Simply Does Not Matter in the majority of
cases.
Meanwhile, what needs to be done is automate the identification of
scriptlet dependencies by resurrecting the patch to bash from RHL 6.2.
That's my opinion anyways.
> I'm not jbj, but here's something related:
> https://bugzilla.redhat.com/118780
> https://bugzilla.redhat.com/118773
>
I am jbj ;-) Not that it matters, sigh.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj@xxxxxxxxxx (jbj@xxxxxxx)
Chapel Hill, NC
