On Jul 7, 2008, at 3:36 AM, Alexey Tourbin wrote:

> On Mon, Jul 07, 2008 at 01:31:55AM -0400, Jeff Johnson wrote:
>> Here's the flaw (from the edos-test*.src.rpm build):
>>
>> ...
>> re --nodeps edos-test-*.src.rpm
>> (cd edos-test && /X/src/wdj/rpm --macros /X/src/wdj/macros:/X/src/ 
>> wdj/
>> tests/macros -q --specfile edos-test.spec && /X/src/wdj/rpm -- 
>> macros /
>> X/src/wdj/macros:/X/src/wdj/tests/macros -q --specsrpm edos-test.spec
>> && /X/src/wdj/rpm --macros /X/src/wdj/macros:/X/src/wdj/tests/ 
>> macros -
>> q --specfile --specedit edos-test.spec && /X/src/wdj/rpm --macros /X/
>> src/wdj/macros:/X/src/wdj/tests/macros -bb --nodeps edos-test.spec)
>>> /dev/null
>> /usr/lib/rpm/check-files: line 11: cd: /X/src/wdj/tests/tmp//edos-
>> test-root: No such file or directory
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>> ^^^
>> ^^^^^^^^^^^^^
>> /X/src/wdj/rpm --macros /X/src/wdj/macros:/X/src/wdj/tests/macros -i
>> --nosignature --nodeps probes-test-*.src.rpm
>
> Hmm, in tests/edos-test.spec, there is no %install section,
> and %buildroot is not created at all.  Also, all %files sections
> are empty there.
>

Yes the edos-test package is a rather pathological corner case,  
radically
different than "normal" packages because there is no content, only
dependency metadata, within the produced binary packages.

I extended rpmbuild to support identically named subpkgs with different
versions mostly because it was easier (for me) to do the extension than
to write and maintain the 10+ individual spec files to capture a single
task, encapsulating an upgrade test problem case in a single build.

There is a need (imho) to extend rpmbuild to use qualifiers other than
name to differentiate packages. Version (and arch and release and
epoch in approximately that order of importance) are the obvious
choices.

The other necessary rpmbuild extension is to permit identical paths with
different content using %{buildroot} as a prefix to distinguish  
identical
paths in subpkgs with different stat(2) data or content.

I can think of a couple approaches to permitting multiple %buildroots.

One way is to permit multiple colon-separated path prefixes with
ordering implicitly used to determine which subpkg uses which buildroot.

Another way would be the analogue of, say, "%description foo" with
a collection of %{buildroot_foo} macros with conventionally created  
names.

A third way might be with subdirs/smlinks in the existing % 
{buildroot} top
level directory.

Dunno which way I like best yet, which is why I haven't attempted an  
implementation.


> And so, there is simply no buildroot.
> Here is how check-files changed:
>
> -RPM_BUILD_ROOT=`echo $1 | sed 's://*:/:g'`
> -
> -if [ ! -d "$RPM_BUILD_ROOT" ] ; then
> -       cat > /dev/null
> +RPM_BUILD_ROOT=$1
> +if ! cd "${RPM_BUILD_ROOT:?}"; then
> +       cat >/dev/null
>         exit 1
>
> Old behaviour was: test for buildroot or exit 1.
> New behaviour: cd to buildroot, or fail noisily and exit 1.
>

Thanks for diagnosis. I can hack around the falw in the edos-test
package by avoiding check-files invocation.

> Let me think!

Here's another thought:

Eliminating check-files as an external helper script entirely is
quite doable. The checks that are being done are quite straightforward.

The main reason that an external script was originally written (my  
guess,
someone at PLD did the implementation) is so that find(1) and diff(1)
could be used.

Well fts(3) as a replacement for file(1), and strcmp/fnmatch instead  
of diff(1),
are rather easy coding, likely less code than what already exists to  
support
an external check-files helper.

Hint: There's example code for doing multi-rooted file tree walks  
using Fts(3) internal
to rpm in tools/rpmmtree.c, tools/rpmdigest.c and (coming soon) tools/ 
rpmwget.c.

Food for thought ;-) The sign sez' "Will work for hacking!"

73 de Jeff