>>>>> "IU" == Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> writes:
IU> This is great. However, in theory, given the naming guidelines, by
IU> stripping the leading "R-" you should get the package name. In
IU> practice, at least one package doesn't adhere to this: R-TH-data,
IU> while the R package name is TH.data, not TH-data. I see that the SPEC
IU> says "# Cannot use . in name", but this is clearly not true (maybe it
IU> was true long ago?).
Why is that a problem? You would just define %packname in that case and
nothing changes.
Look for the 50% case. Does it simplify at least half of the packages
while not making things harder for the rest? I don't know the answer
but I would be surprised if it wasn't 'yes' even if you change 50% to
90%.
IU> That would require a good ton of magic. You have seen something like
IU> this:
IU> %global rlibdir %{_libdir}/R/library
IU> The thing is, this is the path for R packages *with* compiled code,
IU> while R packages *without* compiled code must go to
IU> %_datadir/R/library. That's why every R package has this global on
IU> top of the SPEC.
Well, what you'd generally do is simply use a different macro for the
noarch location and the arch-specific location. So you'd one defined
macro for things under libdir, another macro for things under
datadir. Like Perl and Python and such do.
If you really wanted to get down into it, it's tough to magically define
a macro depending on BuildArch (though I could be missing a trick) but
ou could conceivably have macros like %r_archful_package and
%r_noarch_package.
They could some macro like your %rlibdir and also take care of adding
the build dependencies and (where needed) the BuildArch: line and the
R-core dependency. There's really a whole lot you could do, down to
having macros used in %install, adding that annoying empty %build
section, even generating a file list so you don't have to manually list
so much in %files.
It depends on how far you want to go, and how specific you can be before
you're not actually simplifying a majority of the R packages we have.
- J<
_______________________________________________
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
