On Wed, 28 Jul 2004 00:11:59 -0400 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Wednesday, 28 July 2004, at 02:20:32 (+0300),
> Oded Arbel wrote:
>
> > I think most reasonable persons would agree that learning to rebuild
> > SRPMs is easeir then learning to checkout from CVS.
>
> It was far easier for me to learn how to run "cvs login" and "cvs
> checkout foo" than it was for me to figure out how to redirect rpm
> from /usr/src/redhat to my home directory, which directories to create
> under _topdir, how to invoke rpm in build mode with a spec file, where
> to put all the sources and patches ("so wait...patches are not sources
> in the spec file, but they go in the SOURCES directory? WTF??"),
> etc. Others may have different experiences.
i think he meant - you have a file.tar.gz (with a .spec file in it) or a
.src.rpm - building bianry rpms' from that is childs play - if you are willing
to do it as root :). it's a 2-liner for e stuff
cd ecore
make dist
sudo rpm -ta ecore-1.0.0_pre7.tar.gz
:) i'm not so anal about building as a user :)
> > I'm not talking about copy and paste, but about understanding what
> > is going on.
>
> Understanding what is going on when you rebuild an SRPM is more
> complex, IMHO. CVS is just tossing a bunch of files out in a
it is - doing it right (buildroots, install roots) is a lot of keep track of -
and when things go wrong... uh oh :) assuming its all honkey dory - its easy tho
:)
> directory tree. SRPM's have several sections (%prep, %check, %files,
> %triggerpostun, ...), lots of macros and directives, and so on. Sure,
> learning to run "rpmbuild -ba file.spec" is fairly easy, but there's a
> lot more to it than that.
>
> > Ok. can you do that then, please ?
>
> I plan to; I just haven't had time. I'm working on getting caos-2
> ready for LWCE next week. Maybe if I have time while I'm there...
>
> > That would be useful. thanks for the suggestion. I noticed that
> > several spec files do not have the BuildSuggests entry at all or it
> > does not contain the entries that I think it should have. if I test
> > and report on discrepancies between whats written and what is
> > actually required, will you take a look at adding more information
> > to the BuildSuggests entry ?
>
> Absolutely. The beauty of BuildSuggests: is that they're non-fatal,
> so even if my distro doesn't have a particular package, I can still
> add it as a BuildSuggests: for anyone else whose distro might need
> it. :)
>
> > Not if I do an export. in any case - I always assumed that the
> > tarball/source RPM is a clean snapshot of the source, a.k.a. CVS
> > snapshot/branch.
>
> Negative. Files like "configure" and "config.h.in" and "Makefile.in"
> are NOT in CVS because, like CVS, the autoFUCK tools are developer
> tools. If these files are put into revision control, every time a
> different developer runs autogen.sh, even without making source code
> changes, those files change. And revision control on those files is
> worthless because they're auto-generated.
>
> The tarball created by "make dist" and "make distcheck" contains
> exactly what the developer(s) have said should be there; nothing more,
> nothing less. The end user (or the spec file) should not need libtool
> and automake and such installed; they have only to run ./configure and
> make install. But tarring up a clean cvs export will not include
> these files, and it may include files it shouldn't. "make dist" is
> the best way. After all, it's what the developers themselves do. :)
>
> > I dont understand why, but I'm willing to accept it. I'm currently
> > handling that in the script I'm writing.
>
> I assume you're familiar with the -n option to the %setup macro. The
> default directory name is %{name}-%{version} because that's how the
> vast majority of packages are done. It's packages that don't follow
> the de facto standard that cause spec files to have to throw that -n
> in there.
>
> > If I understand correctly. maintainer-mode is evil (or so it is
> > written). but I see your point. thanks.
>
> I'm not sure where you read/heard that, but it's utter nonsense.
> Maintainer mode (or "make maintainer-clean" in particular) comes in
> very handy for developers. It cleans up auto-generated files which
> should not be under revision control but should be in a dist tarball
> (i.e., files which "make distclean" does not remove).
>
> > Not standard. more of "trying not to break things which other people
> > did" :-)
>
> That's exactly what I'm trying to do. I'm sure everyone is familiar
> with the apache-2.x.x vs. apache2-2.x.x issue, along with glib/glib2
> and several others. Until BuildRequires: gains the ability to handle
> the || (OR) operator, non-fatal buildreq's are (IMHO) the cleanest way
> to tackle this issue.
>
> > Actually - what everyone has. if you want to have your software to
> > built out of CVS, then you need to accept that most people will have
> > only the standard tools that came with their distro (and then only
> > those that sits nicely under the label "you need this to develop and
> > build software".
>
> As I said before, Mezz isn't a requirement. It doesn't do anything
> that you can't do yourself. It just saves the person the trouble of
> changing all those macro values, copying around source tarballs and
> spec files, relocating built packages to the current directory, etc.
> Mezz exists primarily because I got sick of doing the same shit over
> and over by hand. :)
>
> For example, ever needed to create a new patch for an existing SRPM?
> You have to install it (which requires the aforementioned macros and
> directory structure), untar the sources and apply all the patches,
> make your changes, untar and patch *again*, diff the two trees, and
> create your patch file. That gets real old, real fast, let me tell
> you. But with Mezz, this is all it takes:
>
> mzimport -L foo.src.rpm
> cd foo
> mzprep
> *hack hack hack*
> mzpatch -n foo-1.0-some_fix.patch
> mzbuild
>
> Bingo; new SRPM. Again, nothing a person couldn't do him/herself, but
> it sure saves a lot of time (and typing!). :)
>
> Michael
>
> --
> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]>
> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
> "So here we are face to face and heart to heart. I want you to know
> we will never be apart. Now I believe that wishes can come true
> 'cause I see my whole world; I see only you. When I look into your
> eyes, I can see how much I love you, and it makes me realize."
> -- Firehouse, "When I Look into Your Eyes"
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> enlightenment-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
enlightenment-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
