On Tue, Apr 15, 2008, Jeff Johnson wrote:
> 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.
Be careful, although I currently drive OpenPKG with RPM 5.1.0, the
packages itself are still RPM 4 based only. The mega-change which
upgrades them to RPM 5 is still pending as the RPM 5 upgrade itself it
still pending.
> 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.
Well, the perl-util.spec is certainly a nasty example as it contains
many dozen version defines as it is actually a package bundling lots of
Perl modules from CPAN. The usual OpenPKG package has either no such
%defines at all or on average just about one or two.
> 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.
In OpenPKG all macros uses are checked to ensure that the macro is
really defined. But the construct to put a macro at the Version tag is
an often occuring pattern, of course. Mainly because the package Version
in OpenPKG has to be e.g. 1.2b3 while the upstream vendor uses strings
like 1.2-beta3 in its tarball. That's the main purposes of the V_xxxx
version defines in OpenPKG. To smooth out those nasty differences.
> 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.
Yes, I'm fine if RPM 5.2 allows me to remove the "N" from SourceN.
> 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})
Ok, certainly an issue, but harmless for OpenPKG as the perl-xxx bundle
packages are mostly an exception here: the usual OpenPKG package doesn't
use macros in %description as there is usually no need for this. The
bundle packages just need to inform the user that multiple upstream
sources are contained and hence use %description for this.
> 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
Yes, this is already on my list of changes when upgrading the packages
to RPM 5.
> The %clean stanza is likely unnecessary too:
>
> %clean
> rm -rf $RPM_BUILD_ROOT
Yes, at least not in RPM 5 as the macros provide this. But as I said,
the package is still at RPM 4 style and so the stuff is still there.
This is also already on my list of changes when upgrading the packages
to RPM 5 as I know that with RPM 5 and RPM 4 packages _two_ rm(1) calls
are run here.
> Just trying to make suggestions, no sharp criticism is intended.
Yes, no problem. I just should have mentioned that those packages
intentionally are still not at RPM 5 as I first have to officially(!)
upgrade the OpenPKG framework from RPM 4 to RPM 5 and then I can change
the packages. Currently I'm still in-depth testing and so I use the
combination of RPM 5 and RPM 4 packages.
But as OpenPKG packages follow an ultra strict (linted) layout, the
conversion from RPM 4 to RPM 5 style will be mostly automated.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
