https://bugzilla.redhat.com/show_bug.cgi?id=1631988 --- Comment #5 from Neal Gompa <ngompa13@xxxxxxxxx> --- (In reply to Julio Gonzalez Gil from comment #4) > SPEC: > https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/ > fedora-rawhide-x86_64/00801776-s3fs-fuse/s3fs-fuse.spec (committed the > original git repo: > https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/ > f1d7a1fe3af208d05737c33fe33a2e11a1169f14/SPECS/s3fs-fuse.spec) > SRPM: > https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/ > fedora-rawhide-x86_64/00801776-s3fs-fuse/s3fs-fuse-1.84-2.fc30.src.rpm > Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=29823228 > > > A quick glance at the source files for the project indicate that this is actually GPLv2+. Please adjust accordingly. > > Right, I was reading the COPYING file itself and the license configured at > the GitHub repository, but the headers at the source files are GPLv2+ > > > Requires: fuse-libs >= 2.8.4 > > BuildRequires: fuse-devel >= 2.8.4 > > Fuse is required according to the s3fs-fuse README at least for compilation( > https://github.com/s3fs-fuse/s3fs-fuse#compilation), but after a few tries I > noticed it's neither required to build or to run. fuse-libs is enough as you > correctly guessed. I will submit a PR to s3fs-fuse to correct the README. > > I am still keeping a "Requires: fuse-libs >= 2.8.4" as it is needed for > CentOS6/RHEL6 because otherwise the s3fs-fuse will install but will not work > because both distributions have 2.8.3 (while s3fs-fuse requires at least > 2.8.4). > > Obviously fuse 2.8.4 must be obtained from a third-party (I offer the specs > at the same repo). > > Should I add comment about it at the SPEC? > A comment is probably a good idea. When this package is approved, just don't request an EPEL branch for EL6. > > Unversioned Obsoletes are not generally allowed in Fedora, and I don't believe we have an "s3fs" to replace. > > Yes, it seems there was s3fs a long time ago > (https://bugzilla.redhat.com/show_bug.cgi?id=725292#c32), but not anymore. > Removed. > > > "%make_build" is preferred over "make %{?_smp_mflags}". Like "%autosetup", this has been backported to all supported EPEL targets. > > For CentOS7 and Amazon Linux (and I guess in general recent distributions), > it works out of the box without EPEL repositories, but at CentOS6 it > requires EPEL repository present, and then the package epel-rpm-macros > installed. > > Otherwise the macro is not recognized and the build fails. > If you want it to work with "bare" EL6, you can put the following at the top of your spec: %{!?make_build: %global make_build %{__make} %{?_smp_mflags}} (This is not _exactly_ the definition of %make_build, but it is a reasonable fallback) > And given that %{license} macro seems to have the same problem, instead of > having ifs all over the place, I think the best solution is adding a Build > Require: > > > %if 0%{?rhel} == 6 > > BuildRequire: epel-rpm-macros > > %endif > > Is it acceptable? Versions < 6 are out of support, and having "<= 6 breaks" > Amazon Linux. > You can put the following compatibility statement in the %files section just above your usage of %license: %{!?_licensedir:%global license %doc} This works for EL6, SLE11, AMZN1, and other older distributions. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
