there's no question that making the spec file easier to read makes sense.
the only reason it's a mess is because we haven't cared to spend the time to
clean it up. we see it as object code... but we do understand you see it as
and I do like the idea of embedding the cpan2rpm call with parameters into
the spec file. often we have to make use of unusual arguments for special
situations and we forget what those were later. this would solve that
we'll try to get that fixed for the next release.
[mailto:cpan2rpm-general-admin@... Behalf Of bishop
Sent: Tuesday, June 03, 2003 8:03 PM
To: Rob Brown
Subject: Re: [Cpan2rpm-general] Whitespace in generated SPEC
Rob Brown wrote:
> On Tue, 3 Jun 2003, bishop wrote:
>>Am I the only one seeing a lack of whitespace in the generated SPEC? I
>>may be used to my company's policies, but I'm thinking that the specfile
>>that's being built could use some tweeking:
>>%define needs whitespace
>>%define because_it is easier to read
>>%define when things get all stacked up
>>%define rather than
>>%define a big mess of macros
>>%define that take longer to read
>>For starters, that may help.
> I think to better comply with the "man perlstyle"
> guidelines, spaces are used instead of the TAB.
Yeah. Spaces are okay, like I had up there, as long as it's easy to see
where the macro name and value are.
>> Also, some ideas that struck me:
>> - the whitespace in the generation of %build and %install doesn't seem
>>to get into the SPEC, which is unfortuante because /usr/bin/cpan2rpm is
>>pretty easy to read, and the SPEC less so.
> Erick intentionally put this line in cpan2rpm:
> Line 855: ($_ = $spec) =~ s/^\s+//gm; # clean up
> That just wipes all preceding wipespace. (I'm not
> sure why interior space would be collapsed.)
> This was done so that the cpan2rpm code might
> be easier to follow. I don't think much regard
> has gone to trying to make the generated spec
> file easy to read by a human - just functional
> for the rpm robot to parse correctly. :-D
A lot of us, though, do post-generation maintenance. Also, as bad as it
is, distros don't go back to the source for very much, hoping to avoid
getting new errors with new code. It's all patches on the one version
Yeah, it's no good, I know, but I think that a bit of time to pretty up
the spec will make it easier to maintain for those that maintain the
packages after generation. That means more people use the tool, which
means the tool can be made to generate packages that run on all distros,
and that's only good ("good, and good For you," as my brother says, but
he's talking about Guinness at the time).
I think that the #notes in the generated spec are the first thing that'd
be clipped out, because distros like to present a common, clean,
confident look to the source, and in this case the 'source' that's being
provided is the spec file. They/we like it to look the same. I
initially thought this was some kind of "We did this all ourselves" kind
of idea, but after working with a few of them, I noticed that it was a
lot easier to move around the specs when they were free of too many
comments - regardless of distro, because I do a lot of work involving RH
and the odd CL RPM too, and even when looking through a PLD rpm, it's
about the same.
>> - can I recommend <CRLF><CRLF>%section ? I've picked this up from a
>>foreign office.de, and eventually come to like it for %prep through %clean
> Do you mean the --prologue and --epilogue options?
Yeah, that'd be okay, I guess; a \n\n in the prologue would probably
help that one.
That brings up another point or two that I was thinking as I wrote that
one. I noticed that there is no note as to the options used on the
command line that generated the spec. If the goal is to have
maintainers easily and quickly grab a new version of a module - so they
won't be tempted to patch older versions and/or modify the spec - then
what do you think about adding a bit to the comments in the spec file,
that show the command-line arguments used? It'd make it easier to
regenerate the package solely by cpan2rpm, it'd promote the use of ONLY
cpan2rpm to generate the spec file, and maybe make it so that the perl
rpms would eventually have a very similar format.
I know: above, I say that the comments are usually stripped out, but
that's because they're not of immediate use to the maintainer of the
package. I think that's the focus by most distros, too - what does the
maintainer need to know when he comes over to this project for a week to
fix some problem?
>>I looked over the perl at /usr/bin/cpan2rpm, and it's well laid-out, but
>>I have no idea why the whitespace isn't getting in there inside the
>>%sections. Does it gobble whitespace on <<HERE docs? I dunno. In
>>fact, I know so little that I should probably disclaim it: I've only
>>just got my first two Camel Books the other day from Amazon, and the
>>task I'm on now (modernizing an old rh62 layout with specific perl
>>needs) doesn't need a real perl hacker yet; just custom packaging and
>>I'm sorry if I've brought up a FAQ. Please flame me gently, but firmly,
>>and I'll try harder next time.
"In May, for the first time, spam exceeded
legitimate email ..." - MessageLabs Anti-spam Report
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at http://www.etnus.com.
Cpan2rpm-general mailing list