https://bugzilla.redhat.com/show_bug.cgi?id=2216126

Ben Beasley <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]



--- Comment #15 from Ben Beasley <[email protected]> ---
(In reply to surfzoid from comment #14)
> Hi, 
> Builds correctly for x64 and arm64
> I never did anything for other arch, also i see, missing dependencies are
> standard system library.

Packages are expected to build on all primary architectures in Fedora, not just
x86_64; if they don’t, we treat it as a bug and try to fix it. See
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures.

> missing dependencies are standard system library.

If the package doesn’t have the correct dependencies, that needs to be
corrected in the submission. In any case, you shouldn’t have explicit library
dependencies without a documented justification (such as libraries loaded at
runtime with dlopen() rather than linked dynamically):
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_requires.

This needs some work to bring it in line with packaging guidelines. A few
things I see at a glance:

- Conditional macros for other distributions are not permitted:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_legibility.
Same for workarounds like __provides_exclude that aren’t needed in Fedora or in
active EPEL branches.
- Conditional macros for EPEL7 should be removed; EPEL7 reached end of life two
years ago. Same for conditionals for long-since end-of-lifed Fedora releases.
- The License field must be an SPDX expression:
https://docs.fedoraproject.org/en-US/legal/license-field/
- The source archive contains a massive pile of pre-compiled binaries/libraries
and mysterious tarballs. You must remove these in %prep to prove they aren’t
used, and ask upstream not to ship them,
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries.
In this case, I would say even that isn’t enough, and you need to strip them
out of the source archive and document how you’ve done so, as in
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-upstream-uses-prohibited-code.
This is because there are so many binaries, and their origin and nature is so
unclear, that it’s not practical to determine whether they fall under licenses
that allow their distribution in Fedora at all, even in the source RPMs.
- You should not use "%global debug_package %{nil}" without good and explicit
justification,
https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/. Lack of
usable debuginfo suggests that the build is not respecting distribution
compiler flags,
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags, or,
*much worse*, that it includes some of the pre-compiled binaries mentioned
above.
- The spec file uses various obsolete fields and sections, such as Group: and
%clean.
- The spec file does something really dubious with ldconfig, symlinking the
unversioned libz.so from zlib-ng-compat-devel into a private directory as
libz.so.1 and then adding it to the system linker search path. This is probably
an incorrect workaround to linkage issues from shipping pre-compiled binaries.
It certainly needs very clear and detailed explanation and justification.
- All of the %pre*/%post* scriptlets look wrong or obsolete.

The above isn’t by any means a full review, but it gives an idea of the kind of
work that needs to be done before a detailed review would be possible.


-- 
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
https://bugzilla.redhat.com/show_bug.cgi?id=2216126

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202216126%23c15

-- 
_______________________________________________
package-review mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to