On Jul 18, 2008, at 2:09 PM, Jay Soffian wrote:

> On Mon, Jul 7, 2008 at 10:35 AM, Jeff Johnson <n3npq@mac.com> wrote:
>> But I still dunno why a prerequsite relation needs to be  
>> retrofitted into a
>> vendor package ...
>
> Well as expected, the problem is political, not technical.
>
> Customer has group A which delivers an RPM (the "vendor" RPM) which
> behaves differently depending upon the state of the system before it
> is installed.
>
> Customer has group B which wants to put the system into a certain
> state before the vendor RPM is installed. It has chosen to use RPM to
> do this. So we have the desired install order:
>
> - pre-vendor.RPM
> - vendor.RPM
>
> But group B cannot get group A to put a "Requires: pre-vendor" into  
> vendor.RPM.
>

Well, you can influence how rpm orders packages.

A topological sort is a "partial ordering".

Which means there's one degree of freedom in choosing which 1-of-N
packages gets dealt with next.

There are 2 orderings that are possible, the one that's important
for use is that rpm uses the number of incoming dependency
edges to the package node as an "importance" heuristic when
selecting the next package to "partially order".

Which means that your ordering problem to force pre-vendor
to order before vendor package can be solved by adding a
carrier package that has dependencies on _BOTH_ the pre-vendor
and the vendor package, but Requires: the pre-vendor package
multiple times, in order to increase the edge count above
the vendor package, and so the pre-vendor package will
be dealt with before the vendor package.

IOW, you need a "metavendor" package, that carries a single
     Requires: vendor:
and has multiple occurences of, say,
     Requires: pre-vendor
     Requires: /path/in/pre-vendor/file1
     Requires: /path/in/pre-vendor/file2

Note that simply duplicating
     Requires: pre-vendor
multiple times isn't gud enuf, rpmbuild already tries to
uniqify dependencies. One could have
     Requires: pre-vendor <= 100
     Requires: pre-vendor <= 99
until all the bottled dependencies have been consumed ;-)

Kinda hacky, but most definitely increasing the immediate incoming edge
count will cause a package to be ordered before other packages with
fewer immediate incoming edges with all versions of RPM I'm aware of.

Again, the better fix is to rebuild the vendor package, and add
     Requires: pre-vendor
but politics, not engineering have ruled out that solution, and so  
hacks-r-us is all
that can be attempted.

> Anyway, this is not your problem, so I will go beat on the customer
> some more to fix their packaging. However, I thought I'd point out
> that I was surprised by the order here:
>
> $ sudo rpm -U foo-1-0.x86_64.rpm bar-1-0.x86_64.rpm baz-1-0.x86_64.rpm
> baz-1-0 pre 1
> baz-1-0 post 1
> foo-1-0 pre 1
> foo-1-0 post 1
> bar-1-0 pre 1
> bar-1-0 post 1
>
> And I get the same with --noorder as well as --nodeps.
>
> $ rpm -qp --requires foo-1-0.x86_64.rpm | sort -u
> /bin/sh
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>
> $ rpm -qp --requires bar-1-0.x86_64.rpm | sort -u
> /bin/sh
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>
> $ rpm -qp --requires baz-1-0.x86_64.rpm | sort -u
> /bin/sh
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>
> $ rpm --version
> RPM version 4.4.2
>
> $ rpm -q rpm
> rpm-4.4.2-48.el5.x86_64
>
> I realize those last two make this Not Your Problem as this is
> rpm5.org after all, but if you have an insight you can share, it'd be
> appreciated. spec attached and was built with: for n in foo bar baz;
> do rpmbuild -bb --define "name $n" foo.spec; done
>

I haven't a clue what is surprising to you, you have neglected to  
state what
the surprise is or was.

You also have neglected to supply baz and bar reproducers.

And foo.spec is quite sucky too. You cannot use %{name} before Name:  
is processed.

FWIW, see tests/devtool-sanity.spec which does essentially what
you have sent in foo.spec, adding echo's in various scriptlets.

There's also edos-test.spec, which creates a large number of
sub-pkgs with different versions that is used by rpm-5.0 "make check"
ordering and dependency testing.

One of these days you'll start using @rpm5.org, you already keep
coming back for better answers here. Why not switch now? ;-)

But if you send a reproducer for whatever is surprising, I'll explain  
whatever
is going on, as always. RPM isn't rocket science ...

73 de Jeff