public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: William Cohen <wcohen@redhat.com>
Cc: systemtap <systemtap@sources.redhat.com>
Subject: Re: Adding provide to systemtap.spec for systemtap-testsuite rpm
Date: Fri, 01 Feb 2008 17:03:00 -0000	[thread overview]
Message-ID: <47A34F7A.3010307@redhat.com> (raw)
In-Reply-To: <47A23064.7060204@redhat.com>

Hi Will,

William Cohen wrote:
> I haven't seen that effect without bundled_elfutils stap was not required.
> However, I see that there are some lines that fiddle with the __find_provides.

Here is the rpmbuild logs of systemtap-testsuite

$ rpmbuild -bb --with bundled_elfutils systemtap.spec
---
Processing files: systemtap-testsuite-0.6.1-1.fc7
Finding  Provides: /bin/sh -c "/usr/lib/rpm/find-provides | sed '/libelf/d;/libdw/d;/libebl/d'"
Finding  Requires: /bin/sh -c "/usr/lib/rpm/find-requires | sed '/libelf/d;/libdw/d;/libebl/d'"
Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Requires: systemtap dejagnu /bin/sh /usr/bin/env /usr/bin/perl /usr/bin/tclsh stap perl(Getopt::Std)
---                                                                           ^^^^

With bundled_elfutils option, systemtap.spec disables the internal
dependency generator and uses their special filters.
It missed eliminating 'stap' from requires.

$ rpmbuild -bb --without bundled_elfutils systemtap.spec
---
Processing files: systemtap-testsuite-0.6.1-1.fc7
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/sh /usr/bin/env /usr/bin/perl /usr/bin/tclsh dejagnu perl(Getopt::Std) systemtap
---
Without bundled_elfutils, the testsuite package does not require stap.

> The rpmbuild process scans through executable files to find out which 
> interpreters are used by various scripts. There are a number of scripts in the 
> tests that begin with:
> 
> #! stap
> 
> The scanning picks out the interpreter, "stap" and makes it a dependency for 
> systemtap-testsuite.

I guess the rpmbuild solves the absolute path of 'stap' and finds it in
the systemtap package.

> So does it make sense to install systemtap-testsuite without systemtap? If 
> systemtap-testsuite should be installed with systemtap, it seems like the 
> explicit provides would be reasonable.

I agree.
I just think that the testsuite package would better have same "requires"
list regardless of whether the bundled_elfutils option is specified or not.

Thank you,

> 
> -Will

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

      parent reply	other threads:[~2008-02-01 17:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31 14:27 William Cohen
2008-01-31 17:05 ` Masami Hiramatsu
2008-01-31 20:32   ` William Cohen
2008-01-31 21:43     ` Masami Hiramatsu
2008-02-01 17:03     ` Masami Hiramatsu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47A34F7A.3010307@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=systemtap@sources.redhat.com \
    --cc=wcohen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).