#761 Modernize R guidelines
Closed: accepted 2 years ago Opened 2 years ago by qulogic.

Link to the draft

Packaging R draft

Link to diff

https://fedoraproject.org/w/index.php?title=User%3AQulogic%2FPackaging_R_Draft&type=revision&diff=515751&oldid=515681

Explanation

The templates in the existing guidelines use a lot of outdated things; this proposal simply updates them all to current standards. More granular changes can be seen in the history of the page:

  • Use https links (self-explanatory)
  • Remove old spec commands (delete things like %clean or BuildRoot)
  • Fix fedorahosted link (now on pagure.io)
  • Use macros instead of variables (the %{buildroot} form is used by R2spec, so this makes the guidelines consistent with it)
  • Add some more code styling
  • Add dashes in changelog (minor change to be consistent with rpmdev-bumpspec)
  • R-core is not required for arch-specific packages (the requirement is added automatically via a shared library dependency on libR.so; this Requires is already automatically left out by R2spec when it detects an arch-specific package)

Thanks for doing this. I don't think I've even cast a glance at that guideline page since it was first implemented.

Metadata Update from @tibbs:
- Issue tagged with: meeting

2 years ago

After a read-through, I honestly think this is just stuff that I should have been doing as minor cleanups all along, and if someone had pointed out the issues I would have just fixed them directly. So if I do find the time before the meeting then I may just go ahead and make the most obvious of changes and if anything is left over then we can talk about it at the meeting.

Metadata Update from @tibbs:
- Issue assigned to tibbs

2 years ago

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-12/fpc.2018-04-12-16.00.txt):

  • x761 Modernize R guidelines (geppetto, 16:06:01)
  • ACTION: Modernize R guidelines (+1:5, 0:0, -1:0) (geppetto,
    16:10:52)

Metadata Update from @james:
- Issue untagged with: meeting
- Issue tagged with: writeup

2 years ago

While writing this up, I noticed the following section:

Empty %build section

Unlike normal Fedora packages, there is normally no separate %build actions (e.g. %configure)that need to be taken for an R package. However, it is important that all R module packages include an empty %build section, as shown in the spec templates.

Now, that just seems like BS. %build hasn't been required in a specfile for longer than I can remember and I never use it in any of my packages when it's not strictly needed. I think rpmlint will still complain about it for some reason (and should be fixed) but other than that I can't think of anything which would care if %build were missing entirely.

I'm tempted to just remove that section and the empty %build from the spec templates but figured I would see if anyone has a different view before doing that.

Metadata Update from @tibbs:
- Issue untagged with: writeup
- Issue tagged with: meeting

2 years ago

IIRC %build is needed in order to generate debuginfo packages.

According to what I see, debuginfo generation is entirely hung off of %install (which is a macro that expands to the contents of %debug_package followed by a literal %install) and %__os_install_post.

The only magic in %build is done in %___build_pre, but that's also included in every other section (The definitions of %__spec_X_pre include %___build_pre for X in prep, clean, install, check.) This goes back to EL5 at least.

So I really can't see why %build would be necessary.

I had a similar issue with %build recently. If I included (even an empty) %build section, RPM tried to generate a debuginfo package (which failed in this case, because it was a source-only -devel package) - but if I didn't include the empty %build, no debuginfo package was generated. So there is definitely something automagic going on.

I have to think that something else is going on there that's unrelated to the presence of %build, because according to all of the macro definitions I see, no part of debuginfo or debugsrc package generation is related to anything that is done in %build. It all hangs off of %install as I mentioned earlier. I tried with some dummy packages and couldn't come up with any behavior remotely like what you indicate, but maybe I just wasn't trying the right thing.

If I can finish doing writeups I'll do some testing with a few R packages to see if I can detect any changes at all when an empty %build is removed. But if %build is actually necessary then it would be very helpful to have a more concrete example that shows what goes wrong without it.

The verdict on the empty %build section is that @decathorpe was absolutely correct that it does trigger generation of the debuginfo packages. While it is true that the magic behind debuginfo packages is entirely keyed off of things that expand as part of %install, those macros come in depending on the status of two other macros:

%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}

%_enable_debug_packages is obvious. %buildsubdir is quite non-obvious. It's not defined in any macros, but instead internally to RPM. It's documented as follows:

#       The sub-directory (relative to %{_builddir}) where sources are compiled.
#       This macro is set after processing %setup, either explicitly from the
#       value given to -n or the default name-version.
#
#%buildsubdir

and it is set in the doSetupMacro function in build/parsePrep.c in the RPM source. So basically I don't understand, because the spec does have a %prep section and it does call %setup.

I started a thread at http://lists.rpm.org/pipermail/rpm-ecosystem/2018-April/000590.html

I'll go ahead and close this ticket since we now know that the empty %build section does need to be there and no further . If I get any additional information that changes our understanding of this then I'll let everyone know.

Metadata Update from @tibbs:
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

2 years ago

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-26/fpc.2018-04-26-16.00.txt):

  • x761 Modernize R guidelines (geppetto, 16:05:54)
  • ACTION: tibbs vollunteers to build a bunch of R packages with and
    without %build to see if there's a difference. (geppetto, 16:18:58)

Note that within the meeting tibbs had built enough to see that %build was needed.

So it turns out that there's no magic attached to %build; the issue is deep in the vagaries of how RPM parses the spec file. There just needs to be something that ends the %prep section before rpm sees %install. The empty %build section works, but things work fine if you move the %check section up before %install. Or even if you put an empty %clean section there.

I am pretty sure part of the problem is that sections like %install are also macros that you can redefine, and here %install is a macro which will expand to the debuginfo subpackage declarations (if %buildsubdir is defined), followed by %install. But %prep hasn't ended, then %setup hasn't actually been executed yet so %buildsubdir hasn't been defined. Inserting anything that ends %prep fixes the issue; it just so happens that we usually have %build there.

I guess it would be nice if RPM had an explicit section ender like %end. Except, uh, as of 2016 it does; you can stick %end at the end of %prep and things work fine without the %build section. Unfortunately you need rpm 4.14 for that, which means F26 is out and, well, EPEL is in the dark ages.

Login to comment on this ticket.

Metadata