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

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

 



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@xxxxxxxxxxxxxx> 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.

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

http://crashcourse.ca
========================================================================

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux