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'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
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
