On Wed, Oct 31, 2018, 5:01 PM Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx wrote:
On Wed, 31 Oct 2018 at 21:48, Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote:
>
> >>>>> "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%.
Don't get me wrong: I'm totally in with this change. I was just
putting all the information on the table. And I'd be surprised if it
wasn't "yes" for less than 95%. :)
All my packages were created using R2spec, so they would all use %{packname}. I would guess that most packages used the generator as well.
> 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.
>
This can be determined from the NeedsCompilation key in the DESCRIPTION file, which is what (my fork of) R2spec does.
> 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
That is quite annoying, yes. :)
> section, even generating a file list so you don't have to manually list
> so much in %files.
>
Basically anything under %{rlibdir}%{packname} is needed and nothing appears elsewhere. If we didn't need to mark doc and license files, we could have just specified that top-level directory. The hard part about that is the naming is pretty inconsistent. Because CRAN disallows providing the full license text in LICENSE, upstreams that want to follow the terms of the license will put it in a separate file and the name is never the same.
> 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.
In the same way Go has moved to mostly generated, I think R can mostly get away with this as well. We can get most of the information from the DESCRIPTION file or re-write R2spec to output what we need. I don't really know how macros work or I might have attempted this earlier.
> - J<
--
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
