F44 Change Proposal: Adopt new R Packaging Guidelines [SelfContained]

Project Discussion Change Proposals
, ,
1

Adopt new R Packaging Guidelines

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

There are currently over 400 R packages in Fedoraā€™s repositories, many of them with slightly different interpretations of the [R Packaging Guidelines :: Fedora Docs R Packaging Guidelines], which contain almost no automations. As a result, different packages implement different techniques for dealing with the various quirks derived from such guidelines. With this proposal, we aim at automation, reliability and simplicity via [Simplify R spec management by Enchufa2 Ā· Pull Request #2 Ā· rpm-software-management/R-rpm-macros Ā· GitHub newly developed RPM macros], placing R packaging on the same level as other software stacks.

Owner :open_book:

Detailed Description :open_book:

This proposal consists of:

Feedback :open_book:

Some early feedback was gathered from [Making sure you're not a bot! this devel thread], and then implemented in the current proposal:

  • Avoid requiring packagers to set global variables.
  • Try to keep name and version static.
  • Avoid ā€˜ā€˜automagicā€™ā€™-type macros that add lines to the preamble and calculates other macros for later use (i.e. the %foometa approach).

Jelle van der Waa noted that [Making sure you're not a bot! current builds are not reproducible], and proposed a fix. That fix has been incorporated to the `%R_install` macro.

Benefit to Fedora :open_book:

  • Simplicity: with a drastic reduction of boilerplate, spec files are simpler, less error-prone.
  • Automation: the new macros
    ** take care of version normalization, and compute project and source URLs;
    ** have provisions for [[Changes/DynamicBuildRequires]];
    ** automate installation, checks and file generation.
  • Standardization of spec files across the R library.
  • Reproducibility of R package builds.

Scope :open_book:

  • Proposal owners: see detailed description above.
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: update R Packaging Guidelines and get them approved by the FPC.
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact :open_book:

No compatibility impact is expected.

Early Testing (Optional) :open_book:

N/A

How To Test :open_book:

The [iucar/R Copr iucar/R] Copr repo can be used to test the new macros on rawhide. A sample spec file is available in the [PackagingDrafts/R - Fedora Project Wiki guidelines proposal].

User Experience :open_book:

See the [PackagingDrafts/R - Fedora Project Wiki proposed R Packaging Guidelines]. As a result of the simplification of spec files, we may ship updated libraries more quickly, and it may be easier for new contributors to package R packages.

Dependencies :open_book:

N/A (not a System Wide Change)

Contingency Plan :open_book:

  • Contingency mechanism: N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

Documentation :open_book:

N/A (not a System Wide Change)

Release Notes :open_book:

N/A

Last edited by @iucar 2025-10-24T08:34:31Z

Last edited by @iucar 2025-10-24T08:34:31Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what youā€™d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just ā€œ+1ā€. This will make long topics easier to follow.

Please note that this is an advisory ā€œstraw pollā€ meant to gauge sentiment. It isnā€™t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Thanks for your constant work on #R @iucar it is really great to have all the packages in good shape, so if there is time, this effort sounds like a very good idea

1 Like
4

Canā€™t the Fedora R maintainers set up something like r2u where thereā€™s a Fedora repository of all the CRAN and Bioconductor packages converted to RPMs? Iā€™ve used the r2u system and itā€™s really easy - I add an apt repository and when I do an install.package in R, a utility converts that to an apt install and installs the package and all its dependencies as Ubuntu packages.

5

Well, it turns out Iā€™m the author of the utility in question, which was built to support cran2copr and the iucar/cran Copr repository, which has been serving CRAN packages for Fedora since 2020. Then in 2022, Dirk built r2u and adopted that utilty too. So to answer your question, yes, they can, and they did. :wink:

But here we are talking about the official guidelines, and I maintain R itself in the official repos. The current status of the R packages included in the official repos makes it harder and harder for me to update R, and this change would help me a lot.

6

Sounds great. Do I understand correctly that this would also make it easier for maintainers of fedora R packages to have them ā€˜up to dateā€™ (at least at time of a fedora freeze)?

Having cran2copr for development and testing and a more frozen (but recentish) set of R packages in fedora itself would be excellent.

7

Thanks for creating this proposal! I didnā€™t see it mentioned in the proposal but this change should also help make the R packages reproducible.

1 Like
8

Yes, updates should be easier.

1 Like
9

Thanks for that fix, and thanks for noticing. It is mentioned in the new guidelines proposal, but I forgot to mention it in the change proposal. My bad. Fixed now.