'Re: Building RPM's (was: Re: [e-users] can't get embryo_cc to work)'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-users
Subject:    Re: Building RPM's (was: Re: [e-users] can't get embryo_cc to work)
From:       Carsten Haitzler (The Rasterman) <raster () rasterman ! com>
Date:       2004-07-28 5:48:57
Message-ID: 20040728144857.3386c9f2 () localhost
[Download RAW message or body]

On Wed, 28 Jul 2004 00:11:59 -0400 Michael Jennings <e-users@kainx.org> 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/  <mej@kainx.org>
> 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
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
$B7'<*(B - $B<V7/(B ($B?tED(B)                  raster@deephackmode.org
Tokyo, Japan ($BEl5~(B $BF|K\(B)


-------------------------------------------------------
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
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic