On Wed, 2004-07-28 at 01:23, Michael Jennings wrote:
> 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.
I think most reasonable persons would agree that learning to rebuild
SRPMs is easeir then learning to checkout from CVS. I'm not talking
about copy and paste, but about understanding what is going on. simply a
more limited skillset is required. but your argument is valid and I
guess its personal perspective and I will say nothing more :-)
> 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.
The same as /you/ have to acknowledge that my problems may be caused by
your toolset ;-)
> Nope. I thought I already explained this. 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.
Ok. can you do that then, please ?
> 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
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 ?
> > 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.
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.
> Also the
> tarball's top-level path does not include the version number, which is
> a big no-no in most cases.
I dont understand why, but I'm willing to accept it. I'm currently
handling that in the script I'm writing.
> > 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
If I understand correctly. maintainer-mode is evil (or so it is
written). but I see your point. thanks.
> 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.
Not standard. more of "trying not to break things which other people
did" :-)
> Since you seem rather opposed to any build tools other than what
> you're already used to,
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". if you think that everyone that builds out of CVS should have
Mezzanine, then please note so in some sort of documentation (and I
don't consider the mail archives of the user list to be
"documentation").
Thanks for all the info. I'll take a look at what you've wrote and
either integrate this somehow into my system or follow your advice and
just use Mezzanine. I can certainly say that I've learned quite a few
new things in this thread :-)
--
Oded
::..
"Many people lose their tempers merely from seeing you keep yours."
-- Frank Moore Colby
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
enlightenment-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
