On Apr 15, 2008, at 8:21 AM, Ralf S. Engelschall wrote:
>
>
> Find the perl-util.spec under:
> http://cvs.openpkg.org/fileview?f=openpkg-src/perl-util/perl-util.spec
>
> As you can see, it's a regular package which just dependends on  
> "perl".
>

Permit me to point a few items that need to be improved. I've never seen
an OpenPKG spec file until now.

Note that I'm not at all saying that the improvements are needed in the
OpenPKG spec file. There's visibly a great deal of discipline and you
clearly know exactly what you want to do. But perhaps better & simpler
can be arranged with some modest changes.

First of all, the defines

    # versions of individual parts
    %define       V_perl                     5.10.0
    %define       V_alias                    2.32

could likely be easily moved to a different file, with some  
representation
other than macros (if desired).

Even if you wish to continue to use macro strings as a data store,
the information could be moved out of a spec file and replaced
with, say,
      %{load:/path/to/defines.macros}
in the spec file. That path is fully expanded (and URL's are permitted).
What might be needed is a modest change to rpmLoadMacroFile()
to recognize the syntax
      %define foo bar
as identical to
     %foo bar
I keep meaning to add that change no matter what.

Then
     #   package information
     ...
     Version:      %{V_perl}
is an example of the increasing need to use a spec file as
a template, rather than as a recipe. Nothing at all wrong
with putting a macro there if you have the discipline to
ensure the value is correct. But perhaps its time to commit
to a more general framework so that _ANY_ value in a spec file
can be overridden without the need for the artificial explicit syntax
of %{V_perl} in the spec file.

Next is the list/tuple
   #   list of sources
   Source0:      http://www.cpan.org/modules/by-module/Test/Test-% 
{V_test}.tar.gz

I've always thought that N in SourceN: dorectives (same w PatchN) to  
be clunky and tedious.
Adding a different syntax for a tuple, with N assigned by position,  
not by syntax,
is likely a very minor hack in rpmbuild code.


Overloading %description to carry descriptive info is going to cause
some pain when RPM has to commit to an encoding. There's no easy way  
to ensure
that the expanded macros follow the same encoding rules as the  
template does:

  %description
     Perl modules for general utility usage:
     - Alias (%{V_alias})
     - Attribute::Handlers (%{V_attribute_handlers})
     - Class::Container (%{V_class_container})
     - Class::Data::Inheritable (%{V_class_data_inheritable})

The original intent in rpm for %setup was that there would only be a  
single occurence,
with multiple -a/-b etc arguments. rpm has permitted multiple %setup  
directives since
almost forever, but that does not mean that the generated shell is  
very efficient. Examine
the generated %prep scriptlet for what I'm talking about:

   %prep
     %setup -q -c
     %setup -q -T -D -a 1
     %setup -q -T -D -a 2

The %clean stanza is likely unnecessary too:

   %clean
     rm -rf $RPM_BUILD_ROOT

Just trying to make suggestions, no sharp criticism is intended.

73 de Jeff