https://bugzilla.redhat.com/show_bug.cgi?id=1908526
--- Comment #6 from code(a)musicinmybrain.net ---
I was wondering why I had so much trouble finding how to register
info files... Now I understand: it's implicit ;)
It’s frustrating how hard it is to track changes in required scriptlets in
Fedora. Sometimes there is a “Change” you can point to, like
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets, but
sometimes there isn’t. You can see that it was a couple of years ago that the
section about the texinfo scriptlets was removed from the Guidelines
(
https://pagure.io/packaging-committee/c/4485c124280cc138ba9f6cbda3b922a51...).
That history shows the scriptlets were last needed in Fedora 27. They were
removed from the coreutils package, a major user of info pages, around the same
time
(
https://src.fedoraproject.org/rpms/coreutils/c/9cc8a839e2dcb8ca4292245262...,
https://src.fedoraproject.org/rpms/coreutils/c/5decf6eab4c45e52d995f0223d...).
And I can’t even point you to what it was that changed to make the scriptlets
obsolete.
Can you tell me exactly how to see the “link anchor” that is “not found”? If I
know exactly what you’re talking about, maybe I can figure out what is going
wrong.
I do know that there are some rough edges in the documentation build. It’s
trying to download intersphinx inventory 'https://docs.python.org/objects.inv'
to cross-link against other packages’ documentation, and failing because
package builds can’t access the network from mock or koji. There is also a
problem importing opentracing.scope_managers.tornado because upstream is still
not properly compatible with Tornado 6 and later:
https://github.com/opentracing/opentracing-python/issues/136. This is not just
a documentation problem, of course.
Concerning EPEL, this is not the target of this submission, but I
will certainly try to make an EPEL8 package if and when this one succeeds. As far as I
understood, in Fedora this is done by creating a specific branch, so I'll put changes
like "python3-setuptools" in that branch.
Some maintainers prefer “one true spec file” with conditionals for EPEL, while
others prefer to let the branches diverge and keep the spec files cleaner. I
sometimes do “one true spec file” when the differences are trivial, but more
often find myself maintaining separate branches and cherry-picking commits as
you intend to do, especially with Python packages where the RPM macro support
has changed so much.
None of these two seem to exist as Fedora packages. So I think
I'll stick to a manual list of BuildRequires...
This is perfectly reasonable. I certainly wouldn’t package a linter plugin like
flake8-quotes just for this purpose!
Since %pyproject_buildrequires simply prints BR’s to stdout, you can filter
them, e.g.
%generate_buildrequires
( %pyproject_buildrequires -x tests ) | grep -vE 'doubles|flake8-quotes'
or, more conventionally, patch setup.py to remove the unwanted BR’s. Any of
these requires some attention during upstream updates, and falling back to
manual BR’s is probably the simplest choice.
Thanks to your review, I've learned about fedora-review. After
corrections from your input, it still complains about two particular things: a deprecated
package, and Info documentation.
Thanks for pushing the mock change upstream. This is the right thing to do (and
I see your PR was accepted). Please link the upstream bug in a comment above
your patch in the spec file
(
https://docs.fedoraproject.org/en-US/packaging-guidelines/PatchUpstreamSt...).
I believe the diagnostic on info pages is a fedora-review bug (like
https://bugzilla.redhat.com/show_bug.cgi?id=1409315), and one of us should
report it after we’re done here.
This is my first package: I need a sponsor.
Unfortunately, it will be a couple more months until I am eligible to apply for
sponsor status
(
https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor), so I can’t
help out with this part in the short term.
--
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