On Wednesday, 28 July 2004, at 00:51:08 (+0300),
Oded Arbel wrote:
> > rpmbuild -ba --define "_sourcedir $PWD" --define "_specdir $PWD" \
> > --define "_topdir $PWD" --define "%_srcrpmdir $PWD" \
> > --define "_rpmdir $PWD"
>
> That's mighty useful, I didn't know about that. I still think that
> SRPMS are more useful then CVS for building distribution packages as
> they are less steps involved. specificly there are people who don't
> know a thing about CVS but can manage a simple rebuild command.
You're arguing that SRPM's are better because they 1 step instead of
3. That's splitting the hair mighty thin. Anyone who knows how to
invoke rpmbuild --rebuild knows it because someone told them. Thus,
that person is equally able to cut and paste the command I gave.
> Please don't go mud-slinging. I've been using Mandrake for over 5
> years w/o major problems and in the last couple of years w/o any
> problem. I can say the same for almost any distro you choose
> (excluding of course RedHat 6.x and distro with the same outdated
> software, i.e. debian latest stable), but I won't.
Nobody's slinging mud. In my experience, Mandrake is too
bleeding-edge for their own good. If it works for you, fine, but you
have to acknowledge that problems may be caused by your toolset/distro
choice.
> Thanks - that did the trick. can you please add libungif-devel as
> BuildRequires for the imlib2 spec file ?
Nope. I thought I already explained this. imlib2 does NOT require
the libungif-devel package. It requires the GIF library and its
headers. This may or may not correspond to a package called
libungif-devel on any particular distro. Instead, requiring
/usr/include/gif_lib.h and /usr/lib/libgif.so accomplishes the same
thing (given a good dep solver) without being distro-specific.
> Thanks. is it possible that it be put in the e17 CVS like the rest
> of the spec files ?
I'll commit it shortly.
> I don't use Messaine and I don't use yum (I have used it several
> times, including as recent as FC2, and I still think urpmi is way
> better). see below.
Doesn't matter what you use. Mezzanine can handle anything that it
can pass package names to for installation, preferably in a non-fatal
way.
If you refuse to use Mezzanine, you can always add something like this
to your script before calling rpmbuild:
perl -pi.bak -e 's/\#BuildSuggests/BuildRequires/g' *.spec
> I thought that I can make a dist ball just by running the
> auto-tools, and packaging the CVS directory after that. can you
> please explain what's wrong with this approach?
CVS directories and other junk end up in the tarball. Also the
tarball's top-level path does not include the version number, which is
a big no-no in most cases. The "make dist" command is there for
precisely this reason.
> The problem I'm having (IMHO anyway - it may all be just in my mind)
> is that running configured/make and friends changes a lot of files
> in the CVS dir, and thus making the next build only as clean as make
> distclean can make it - which is as usall an error-prone process. I
> rather build stuff out of as clean as dist as possible, with the
> least ammounts of steps that can go wrong. I think that packaging
> the CVS dir as it comes out of the CVS and building off that is the
> ultimate goal and I sometimes do that.
That would be unfortunate. You're better off invoking autogen like
this:
make maintainer-clean
./autogen.sh --enable-maintainer-mode
make dist
> There are ways to add BuildRequires in a way that is not (or at
> least - as little as possible) distribution dependant.
Mine is one of them. If you know of others, by all means, speak up.
I am in frequent contact with Jeff Johnson (RPM lead developer) and
have yet to hear of any such standard, but perhaps I just missed it.
Since you seem rather opposed to any build tools other than what
you're already used to, I'll show you how Jeff proposed doing it.
First, you'll need to create a directory full of files. Each file's
name is the package name and its contents are the buildreq's for that
package. Then put the following macros in your ~/.rpmmacros (or other
macros) file:
%description \
# %{suseneeds} # %{mdkneeds} # %{rhelneeds} # %{caosneeds} \
%{expand:%%undefine description} \
%%description
%mdkneeds \
BuildRequires: /dev/null %(cat /path/to/hintfiles/%{name} 2>/dev/null) \
%{nil}
> I don't think its fair to assume that just because something was
> broken in the past it will always and forever be broken (see
> Mandrake comment above).
I don't assume that. But it is broken *now*, and I'm developing
*now*. If things change in the future, we'll change with them.
> Oh, come on. this is not fair. I can just as well say that my
> problem is you using non-standard tools in an undocumented way and
> expecting people to magically know that and use them
I don't. Mezzanine is not required. It just makes it easier. In
fact, that's why Mezzanine exists: it makes lots of things easier.
Building packages from CVS checkouts is just one of those things.
> (I actually grepped the CVS tree for "mezzanine" and failed to find
> any reference).
I gave the URL in my original e-mail.
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)
-----------------------------------------------------------------------
"I gather myself around my faith, for the Light is the Darkness
most feared." -- Jewel, "Hands"
-------------------------------------------------------
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
