Bug 1301219 - Review Request: racket - Racket is a full-spectrum programming language [NEEDINFO]
Review Request: racket - Racket is a full-spectrum programming language
Status: NEW
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
: 808350 (view as bug list)
Depends On:
Blocks: FE-NEEDSPONSOR
  Show dependency treegraph
 
Reported: 2016-01-22 17:00 EST by Brandon Thomas
Modified: 2017-07-06 10:13 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dbenoit: needinfo?


Attachments (Terms of Use)

  None (edit)
Description Brandon Thomas 2016-01-22 17:00:28 EST
Spec URL: https://drive.google.com/file/d/0B8sH_bCHJO3BQnJ5Q29jQjc1R28/view?usp=sharing
SRPM URL: https://drive.google.com/file/d/0B8sH_bCHJO3BLWdPUzRQcVpKSFk/view?usp=sharing
Description: Racket is a full-spectrum programming language. It goes beyond
Lisp and Scheme with dialects that support objects, types, laziness,
and more. Racket enables programmers to link components written
in different dialects, and it empowers programmers to create new,
project-specific dialects. Racket's libraries support applications from
web servers and databases to GUIs and charts.

Koji Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=12652259

Fedora Account System Username: bthomaszx@gmail.com

This is my first package, and I need a sponsor. I though it was strange that Fedora doesn't include Racket, so I built it and I can maintain it to the best of my ability.
Comment 1 Neal Gompa 2016-01-22 17:34:43 EST
Could you please put it somewhere that is easily accessible?

For example, you could use Copr to upload the SRPM and have it build there, and then go ahead and link us to the Spec in dist-git and the SRPM in the repo directory.

Also, your FAS user is not your email address. Please provide the correct FAS username.
Comment 2 Zbigniew Jędrzejewski-Szmek 2016-01-22 19:10:27 EST
*** Bug 808350 has been marked as a duplicate of this bug. ***
Comment 3 Brandon Thomas 2016-01-23 10:29:31 EST
Oh, sorry!

Fedora Account System Username: bthomas

Spec URL: http://copr-dist-git.fedorainfracloud.org/cgit/bthomas/racket/racket.git/plain/racket.spec?id=6d83ebe32b8a565d813ce0a0ff3e20125316b4a0
SRPM URL: https://copr-be.cloud.fedoraproject.org/results/bthomas/racket/fedora-23-x86_64/00155292-racket/racket-6.3-1.fc23.src.rpm

I ran the build on Copr, and it fails for rawhide, but works for Fedora 21, 22 and 23. I haven't found any related bugs upstream. I'm going to try to drill down on this some more to create a patch and isolate what changed in rawhide.
Build Log (rawhide): https://copr-be.cloud.fedoraproject.org/results/bthomas/racket/fedora-rawhide-x86_64/00155292-racket/build.log.gz
Comment 4 Neal Gompa 2016-01-23 13:21:47 EST
Now that I can see your spec, I see a few things you can correct pretty quickly.

* You do not need to do the export CFLAGS bit, as %configure handles that.

* %configure instead of %{configure}. I'm a bit hazy on this, but I think using %{configure} can mess up some circumstances (but I'm not sure). In any case, it makes stylistic sense to use %configure there anyway.

* %make_build instead of make %{?_smp_mflags}. Unless you are targeting EPEL with this, you should use this instead, as it's cleaner and more obvious what it is. (Actually, I believe %make_build now works in EL7 at least, so you could probably get away with using it even there). 

* %make_install instead of "make install %{?_smp_mflags} DESTDIR=${RPM_BUILD_ROOT}". Unless there's a very good reason to, you should use %make_install.

* Unless you are targeting EL5, you do not need a %clean section.

* Instead of using ExclusiveArch, use "ExcludeArch: %{arm}", as you indicate that only ARM is failing right now. Generally, you should only exclude architectures that don't work, rather than making it only build on a subset of architectures.
Comment 5 Upstream Release Monitoring 2016-01-23 17:26:52 EST
bthomas's scratch build of racket-6.3-1.fc23.src.rpm for f24 completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12664534
Comment 7 Neal Gompa 2016-01-24 03:48:00 EST
You don't need "rm -rf ${RPM_BUILD_ROOT}" in the install step. rpmbuild automatically cleans the build root before starting %install.

Other than that, I don't see anything standing out to me.
Comment 8 Neal Gompa 2016-01-24 03:49:41 EST
Also, adding FE-NEEDSPONSOR, since this is your first package review.
Comment 10 Brandon Thomas 2016-01-25 11:38:50 EST
I based the above spec off of a previous attempt, and it has the same breakdown as before (racket and racket-devel), but I think I can break the package down a bit better. Because this is often used as an introductory language in higher education, I want to try to make this as non-confusing as possible to new programmers. So I propose the following breakdown:

racket-core: Core Racket components
racket-gtk: Graphical Racket components (requires: racket-core)
racket-doc: Racket documentation
racket-devel: Libraries to link with Racket
racket-ide: The DrRacket IDE for Racket (requires: racket-gtk)
racket: The complete Racket distribution (requires: racket-ide, racket-doc)

It is backwards compatible with previous attempts at adding Racket to Fedora (including the spec files above). I decided against calling "racket-ide" as "drracket", because lots of people think that DrRacket is the name of the entire distribution, and they might install that thinking they're installing everything, only to get mad when the documentation feature of drracket doesn't work (and as a new programmer who isn't familiar with Linux, it can be frustrating).
AFAIK, there isn't a list of packages that require graphical libraries, but here's what I can see off of the bat (usr/share/racket/pkgs): draw, draw-lib, future-visualizer, future-visualizer-typed, games, gui, gui-lib, gui-pkg-manager-lib, images-gui-lib (I want to keep some images functionality for servers running racket, if it doesn't break anything), pict (unfortunately I don't think I can break off just the gui component), pict-doc, pict-lib, pict-snip, picturing-programs, plot-gui-lib (again, I want to keep some plot functionality if possible), rackunit-gui, redex-gui-lib, slideshow, slideshow-exe, slideshow-lib, slideshow-plugin. And for DrRacket: drracket, drracket-plugin-lib, drracket-tool.

What to people think? Should I keep it the same as before, or should I try to break it down like this?
Comment 11 Jens Petersen 2017-01-03 22:21:10 EST
I am completely new to racket, but overall your approach sounds reasonable.
It would probably be ideal if interdependencies (Requires) could be
autogenerated.
I would suggest experiementing with the packaging first in Copr.


For others: most current copr currently seems to be:
https://copr.fedorainfracloud.org/coprs/jsouthworth/racket/
Comment 12 Jens Petersen 2017-01-03 22:40:14 EST
However it might be better to first get the current package into Fedora. :)

While it is good you have plenty of comments, it makes the rpm fields/headers
at the top of the spec file a bit hard to read.

It would be good to do another koji scratch build since aarch64 and ppc64le
have been added as new archs to F26 Rawhide.
Comment 13 Saša Janiška 2017-03-05 11:07:59 EST
Racket language does deserve, imho, to be present in the distribution like Fedora, so please help to make it happen!
Comment 14 David Benoit 2017-07-06 10:13:55 EDT
Has there been any progress on this?  I'd love to see Racket in the Fedora repositories.  Is there anything I can do do help move this along?  

I've never submitted a package for review before.  If I start a new rpm build with updated sources, should I open a new Bugzilla report, or post here?

Note You need to log in before you can comment on or make changes to this bug.