Re: Use immutable CRAN URLs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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%. :)

> 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

That is quite annoying, yes. :)

> 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<

-- 
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux