Sorry, Ralf. Only a curiosity on OPENPKG packaging.

Why most package have:

AutoReq:      no
AutoReqProv:  no


I doesn't like this never. OTHO i like automatic dependency resolution .

Sure, it is also true that i am lazy

Regards

On Tue, Apr 15, 2008 at 7:31 PM, Ralf S. Engelschall
<rse+rpm-devel@rpm5.org<rse%2Brpm-devel@rpm5.org>>
wrote:

> 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
>                                       rse@engelschall.com
>                                       www.engelschall.com
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org
>