All this would be very useful. CRAN guidelines are pretty strict, and
they are enforced by R packaging and checking tools, and additionally
upon submission to CRAN, with many automatic checks. As a result, and
as you say, most SPEC sections in most packages can be fully
automated, and I think we should tend to that, with proper mechanisms
to treat special cases.
Let me add to your findings from my experience as both R and Fedora
package maintainer:
- Version: As you already found out, there are many version formats
allowed. The only special cases are those using a hyphen, such as
R-uuid, that needs to be substituted with a dot. Other formats may
contain two or three components, year and month... but they don't
require special treatment if there are no hyphens.
- Arch, Requires, BuildRequires, libdir/datadir: As Elliott pointed
out already, archful packages can be detected just by looking into the
DESCRIPTION file, by checking whether the NeedsCompilation flag
exists. If it does, the package must go to libdir and R-devel must be
added as BuildRequires. Furthermore, the LinkingTo field in the
DESCRIPTION file lists packages that must be added as BuildRequires,
such as R-Rcpp-devel. If NeedsCompilation does not exist, the package
must go to datadir, noarch needs to be specified and R-core must be
added as Requires. Further Requires usually are a little bit trickier
to automate and should be managed by us.
- Package devel: This could be automated also. LinkingTo other R
packages is possible if headers are listed under inst/include (in the
sources; the installation path is %{rlibdir}/%{packname}/include) in
those packages. So the R-%packname-devel package must be defined if
such directory exists. There are two flavors for this: packages that
NeedsCompilation, so they are archful, and packages that don't. The
latter are devel-only (see, e.g., R-BH).
- %prep, %build, %install, %check, %files: These can be automated too.
%build (void) and %install are always the same. %prep and %check may
require some tuning (patching, unbundling; defining some exports and
setting some flags in the "R CMD check" command). %files are pretty
standard: there is a basic set, and then other may or may not be
there, such as LICENSE/LICENCE, NEWS/NEWS.md, README/README.md,
Changelog, and CITATION; and directories such as libs and include.
I'm not familiar at all with RPM macros, but I can help with all these details.
On Thu, 1 Nov 2018 at 03:22, Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote:
>
> And with some tweaks to the macro file (current version at
> https://www.math.uh.edu/~tibbs/fedora/macros.test) and the R-uuid
> package is reduced to the following. Not quite as simple, but it shows
> how you can still split out the individual sections when you need to add
> something, and also cope with a difficult version number. (I switched
> the argument order around for %cran_source.)
>
> Sadly you still need %build if not using %r_simple_archful_package. I
> could explain why but....
>
> Name: R-uuid
> Version: 0.1.2
> Release: 6%{?dist}
> Summary: Tools for generating and handling of UUIDs
>
> License: MIT
> URL: %cran_url
> Source0: %cran_source 0.1-2
>
> BuildRequires: libuuid-devel
>
> %description
> Tools for generating and handling of UUIDs (Universally Unique
> Identifiers).
>
> %r_archful_package
>
> %prep
> %r_prep
>
> pushd %{packname}
> rm configure.ac configure src/Makevars.in src/[a-z]*.[ch]
> sed -i -e '/configure/d' -e '/Makevars/d' -e '/src\/[a-z].*.[ch]/d' MD5
> rm -r src/config.h.in src/win32
> sed -i -e '/config.h/d' MD5
> cat > src/Makevars << EOF
> PKG_CFLAGS = \$(shell pkg-config --cflags uuid)
> PKG_LIBS = \$(shell pkg-config --libs uuid)
> EOF
> popd
>
> %build
>
> %install
> %r_install
>
> %check
> %r_check
>
> %files -f %packname.files
>
> %changelog
--
Iñaki Ucar
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
