[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: why do source rpms have "prep" dependencies?

On Sun, 9 Sep 2007, Andy Green wrote:

> Somebody in the thread at some point said:
> > On Sun, 9 Sep 2007, Frank Cox wrote:
> >
> >> On Sun, 09 Sep 2007 03:47:33 -0400 (EDT)
> >> "Robert P. J. Day" <rpjday mindspring com> wrote:
> >>
> >>> if someone wants to simply RTFS, it's a bit disconcerting to learn
> >>> that you need to download another five source rpms to do it.
> >> I don't know if this is useful in your situation, but I'm pretty
> >> sure File Roller can "look inside" of srpm files and extract the
> >> contents for you as desired.
> >
> > that might come in handy, but it still doesn't solve the fundamental
> > problem of why a source rpm's "BuildRequires" value should affect the
> > simple tarball extraction and patch application operation.
> >
> > just for fun, i edited mkinitrd's spec file and deleted all the
> > "BuildRequires" lines, and the build prep worked just fine, so i'm
> > convinced that a simple prep should be possible without taking the
> > BuildRequires dependencies into account.  now i just want an option
> > that implements that.
> >
> > well ... what are you just sitting there for?  get to work.  :-)
> Not sure I got the point across that the %prep section in the spec
> can contain arbitrary commands, not just %setup and %patch.  Those
> arbitrary commands might be executing things that are provided by
> the BuildRequires.

no, i caught that.  but my point is that, if someone wants to simply
RTFS, is any of that extra post-patch processing going to change the
source?  if not, then it's utterly irrelevant to the issue at hand,
and there should be an easy way for someone to download a source rpm,
unload the tarball and apply the patches without going any further and
getting hassled by all the BuildRequires stuff.

> You can then say, well, it should look at %prep and decide whether
> to pull the BuildRequires in or not, but that sounds like a bad idea
> in terms of complexity for a crummy "feature".  You're presumably
> planning to rebuild the thing at some point anyway.

i don't think that's a safe assumption at all -- i don't think it's
rpmbuild's job to guess what i'm eventually going to do with my
downloaded source rpm.  my case is a perfect example -- i just want to
see the source code for "nash", nothing more.  so an additional
rpmbuild option to simply untar and patch seems like a reasonable (and
trivial) suggestion.

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]