Spec URL: https://jruzicka.fedorapeople.org/pkgs/libyang2.spec SRPM URL: https://jruzicka.fedorapeople.org/pkgs/libyang2-2.0.7-1.fc34.src.rpm Description: libyang is a YANG data modelling language parser and toolkit written (and providing API) in C. Fedora Account System Username: jruzicka
Please note that the .spec/SRPM is generated from upstream sources using apkg, the .spec template is included upstream: https://github.com/CESNET/libyang/blob/master/distro/pkg/rpm/libyang2.spec Furthermore, the .spec has been extensively tested by both libyang2 and apkg CI systems on many different distros - it's known to build and install on Fedora, CentOS, Rocky, and SUSE. Fedora already contains libyang v1 but it's incompatible with v2 so I requested a new libyang2 package instead. Let me know if there are any issues.
(In reply to Jakub Ruzicka from comment #1) > Please note that the .spec/SRPM is generated from upstream sources using > apkg, the .spec template is included upstream: > > https://github.com/CESNET/libyang/blob/master/distro/pkg/rpm/libyang2.spec > > Furthermore, the .spec has been extensively tested by both libyang2 and apkg > CI systems on many different distros - it's known to build and install on > Fedora, CentOS, Rocky, and SUSE. > > Fedora already contains libyang v1 but it's incompatible with v2 so I > requested a new libyang2 package instead. > It would probably be better to update libyang to v2 and then build a libyang1 compat package that doesn't ship the tools. Also, this libyang2 package spec massively fails to comply with our guidelines.
(In reply to Neal Gompa from comment #2) > > It would probably be better to update libyang to v2 and then build a > libyang1 compat package that doesn't ship the tools. Probably better how/why? This naming convention was chosen after a discussion with both upstream and the Debian package maintainer as a least problematic transition with same package names across distros given the incompatibility between v1 and v2 (which IMHO warrants separate packages). Considering your suggestion, where would the libyang1 compat package live? In libyang2 distgit/branch? In a separate libyang1 distgit/branch? > > Also, this libyang2 package spec massively fails to comply with our > guidelines. It's an upstream compromise that works on all distros, I don't expect it to go into Fedora as is. However, I've hoped for specific pointers on howto resolve the most pressing issues such a v1 vs v2 naming, Conflicts (which Fedora guidelines advise against) or other fundamental issues. I can fix the upstream source URL, changelog and other nits fedora-review tool points out at any time, but it's pointless without addressing the core issues mentioned before. If you care to elaborate on the most important steps required to make the .spec comply with Fedora guidelines, I'm happy to carry those changes out. Upstream is cooperative as well. The .spec is ~80 lines and there exists a finite sequence of edits that lead to a Fedora-compliant .spec.
Spec URL: https://jruzicka.fedorapeople.org/pkgs/libyang2.spec SRPM URL: https://jruzicka.fedorapeople.org/pkgs/libyang2-2.0.7-1.fc34.src.rpm fedora-review was picking the wrong .spec (the upstream template), hope this comments fixes it.
I've fixed (in-place) all the issues pointed out by fedora-review (now with correct .spec file) and rpmlint except few missing doc/man warnings.
(In reply to Jakub Ruzicka from comment #3) > (In reply to Neal Gompa from comment #2) > > > > It would probably be better to update libyang to v2 and then build a > > libyang1 compat package that doesn't ship the tools. > > Probably better how/why? > > This naming convention was chosen after a discussion with both upstream and > the Debian package maintainer as a least problematic transition with same > package names across distros given the incompatibility between v1 and v2 > (which IMHO warrants separate packages). > > Considering your suggestion, where would the libyang1 compat package live? > In libyang2 distgit/branch? In a separate libyang1 distgit/branch? > It would live in a separate libyang1 Dist-Git repository. You can see how we did it for OpenSSL here with openssl1.1: https://src.fedoraproject.org/rpms/openssl1.1 Compatibility packages are exempted from requiring review: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process For the legacy libyang1 package, we do not need to ship the libyang-tools package, since the tools provided there would be the same as what libyang (upgraded to v2) would include. > > > > Also, this libyang2 package spec massively fails to comply with our > > guidelines. > > It's an upstream compromise that works on all distros, I don't expect it to > go into Fedora as is. > > However, I've hoped for specific pointers on howto resolve the most pressing > issues such a v1 vs v2 naming, Conflicts (which Fedora guidelines advise > against) or other fundamental issues. I can fix the upstream source URL, > changelog and other nits fedora-review tool points out at any time, but it's > pointless without addressing the core issues mentioned before. > > If you care to elaborate on the most important steps required to make the > .spec comply with Fedora guidelines, I'm happy to carry those changes out. > Upstream is cooperative as well. > > The .spec is ~80 lines and there exists a finite sequence of edits that lead > to a Fedora-compliant .spec. Actually, if you take a look at the existing libyang spec file, it's already in pretty decent shape: https://src.fedoraproject.org/rpms/libyang/blob/rawhide/f/libyang.spec
Created attachment 1802124 [details] Patch to upgrade libyang to version 2.0.7 Here's what it would look like to upgrade libyang to v2...
Created attachment 1802138 [details] Updated patch to upgrade libyang to version 2.0.7
If you wish to proceed with libyang2 instead of upgrading libyang, then the patch applied on the libyang spec file is more or less what I expect to see.
(In reply to Neal Gompa from comment #6) > > It would live in a separate libyang1 Dist-Git repository. > > You can see how we did it for OpenSSL here with openssl1.1: > https://src.fedoraproject.org/rpms/openssl1.1 > > Compatibility packages are exempted from requiring review: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ > #_package_review_process > > For the legacy libyang1 package, we do not need to ship the libyang-tools > package, since the tools provided > there would be the same as what libyang (upgraded to v2) would include. Thanks for clarification. That makes perfect sense in a case of forward compatible v1 -> v2 where previous packages requiring libyang (v1) would work with v2 but IIUC libyang v2 is a big overhaul that's closer to a new library. This would effectively break all depending packages on upgrade - thus the explicit libyang2 plan. libyang-tools need to be moved out of v1 package either way - good point. > Actually, if you take a look at the existing libyang spec file, it's already > in pretty decent shape: > https://src.fedoraproject.org/rpms/libyang/blob/rawhide/f/libyang.spec We probably should've used that as a base instead of the upstream .spec... Well, regardless, there are many differences for v2 including different requires, build options, no python bindings, and more... it really felt like packaging a different library. After dropping all unnecessary things with the help of upstream, only the new .spec remained. Thanks for input, Neal. I'll discuss this with upstream further before proceeding. I think both ways have their (dis)advantages so it boils down to real relation between v1 and v2 and the effects of potential upgrade for existing users of the package.
(In reply to Neal Gompa from comment #9) > If you wish to proceed with libyang2 instead of upgrading libyang, then the > patch applied on the libyang spec file is more or less what I expect to see. After due consideration I still slightly prefer libyang2 as opposed to libyang upgrade to v2 because: * v1 and v2 are API incompatible - packages depending on libyang would break upon upgrade * no changes needed on future v3 etc. - requires will already be version-explicit * Debian maintainer expressed intent to also use libyang2 so having consistency across distros is a nice bonus for users I've aligned my .spec with the Fedora libyang distgit (which you updated to modern standards - thanks!) as much as possible effectively arriving at equivalent of the patch you kindly provided with few tiny changes, notably: * removed confusing arch-independent builddir - docs seem to build fine without it now * added libyang2-tools Provides: libyang-tools = %{version}-%{release} - does this make sense to replace legacy libyang-tools after the subpackage is removed from libyang1? Just an idea... Spec URL: https://jruzicka.fedorapeople.org/pkgs/libyang2.spec
> * removed confusing arch-independent builddir - docs seem to build fine without it now This is because I changed redhat-rpm-config in F35+ to fix it: https://src.fedoraproject.org/rpms/redhat-rpm-config/c/e0cfcc0fc76a7642faabb25c5e348d6a1314ace2?branch=rawhide (I hope we get this in RHEL 9 too, it would suck dealing with this problem even longer...) For older releases, you'll still need the override. > * added libyang2-tools Provides: libyang-tools = %{version}-%{release} - does this make sense to replace legacy libyang-tools after the subpackage is removed from libyang1? Just an idea... I think it does make sense to do that. You'd probably want Obsoletes+Provides there. Furthermore, in the spec, I see you've got this: > # v1 and v2 have incompatible API > Conflicts: libyang This is actually not necessary, since libyang2 and libyang have no file conflicts. You do, however, need them for -devel and -devel-doc packages.
(In reply to Neal Gompa from comment #12) > This is because I changed redhat-rpm-config in F35+ to fix it: > https://src.fedoraproject.org/rpms/redhat-rpm-config/c/ > e0cfcc0fc76a7642faabb25c5e348d6a1314ace2?branch=rawhide > > (I hope we get this in RHEL 9 too, it would suck dealing with this problem > even longer...) > > For older releases, you'll still need the override. I see, leaving it there. > > * added libyang2-tools Provides: libyang-tools = %{version}-%{release} - does this make sense to replace legacy libyang-tools after the subpackage is removed from libyang1? Just an idea... > > I think it does make sense to do that. You'd probably want > Obsoletes+Provides there. OK, I've added Obsoletes: libyang-tools < 2 > This is actually not necessary, since libyang2 and libyang have no file > conflicts. > > You do, however, need them for -devel and -devel-doc packages. Oh right, it's nice at least the libs themselves can be installed alongside each other. I've shuffled the Conflicts as you suggest.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [x]: ldconfig not called in %post and %postun for Fedora 28 and later. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "BSD (3 clause)", "BSD (2 clause)". 368 files have unknown license. Detailed output of licensecheck in /home/ngompa/1982306-libyang2/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/share/doc/libyang(libyang-devel-doc), /usr/share/doc/libyang/html(libyang-devel-doc), /usr/share/doc/libyang/html/search(libyang-devel-doc), /usr/include/libyang(libyang-devel, libyang-cpp-devel) [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [-]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [x]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 0 bytes in 0 files. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: The placement of pkgconfig(.pc) files are correct. [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: libyang2-2.0.7-1.fc35.x86_64.rpm libyang2-tools-2.0.7-1.fc35.x86_64.rpm libyang2-devel-2.0.7-1.fc35.x86_64.rpm libyang2-devel-doc-2.0.7-1.fc35.noarch.rpm libyang2-debuginfo-2.0.7-1.fc35.x86_64.rpm libyang2-debugsource-2.0.7-1.fc35.x86_64.rpm libyang2-2.0.7-1.fc35.src.rpm libyang2.x86_64: W: no-documentation libyang2-tools.x86_64: W: spelling-error Summary(en_US) validator -> lavatorial libyang2-tools.x86_64: W: spelling-error %description -l en_US validator -> lavatorial libyang2-tools.x86_64: W: no-manual-page-for-binary yangre libyang2-devel.x86_64: W: description-shorter-than-summary libyang2-devel.x86_64: W: no-documentation libyang2-devel-doc.noarch: E: devel-dependency libyang2-devel libyang2-devel-doc.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/libyang/html/cesnet-style.css 7 packages and 0 specfiles checked; 1 errors, 7 warnings. Rpmlint (debuginfo) ------------------- Checking: libyang2-tools-debuginfo-2.0.7-1.fc35.x86_64.rpm libyang2-debuginfo-2.0.7-1.fc35.x86_64.rpm 2 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- Cannot parse rpmlint output: Source checksums ---------------- https://github.com/CESNET/libyang/archive/v2.0.7/libyang-2.0.7.tar.gz : CHECKSUM(SHA256) this package : b3b74ce39406db7c1e440b675fb4c2d87b042667ed17bcd77c70f77230afb41c CHECKSUM(SHA256) upstream package : b3b74ce39406db7c1e440b675fb4c2d87b042667ed17bcd77c70f77230afb41c Requires -------- libyang2 (rpmlib, GLIBC filtered): glibc ld-linux-x86-64.so.2()(64bit) libc.so.6()(64bit) libpcre2-8.so.0()(64bit) rtld(GNU_HASH) libyang2-tools (rpmlib, GLIBC filtered): glibc libc.so.6()(64bit) libyang.so.2()(64bit) libyang2(x86-64) rtld(GNU_HASH) libyang2-devel (rpmlib, GLIBC filtered): /usr/bin/pkg-config libyang.so.2()(64bit) libyang2(x86-64) pkgconfig(libpcre2-8) libyang2-devel-doc (rpmlib, GLIBC filtered): libyang2-devel libyang2-debuginfo (rpmlib, GLIBC filtered): libyang2-debugsource (rpmlib, GLIBC filtered): Provides -------- libyang2: libyang.so.2()(64bit) libyang2 libyang2(x86-64) libyang2-tools: libyang-tools libyang2-tools libyang2-tools(x86-64) libyang2-devel: libyang2-devel libyang2-devel(x86-64) pkgconfig(libyang) libyang2-devel-doc: libyang2-devel-doc libyang2-debuginfo: debuginfo(build-id) libyang.so.2.1.4-2.0.7-1.fc35.x86_64.debug()(64bit) libyang2-debuginfo libyang2-debuginfo(x86-64) libyang2-debugsource: libyang2-debugsource libyang2-debugsource(x86-64) Generated by fedora-review 0.7.6 (b083f91) last change: 2020-11-10 Command line :/usr/bin/fedora-review -b 1982306 -m fedora-rawhide-x86_64 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, C/C++, Shell-api Disabled plugins: fonts, R, Perl, SugarActivity, Haskell, PHP, Ocaml, Java, Python Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH
Everything looks good, so... PACKAGE APPROVED.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/libyang2
Hi guys, I understand the reasons that Jakub described here in the comments, why it is a good idea to make this into a new package, but next time please make sure you invite the maintainer of the current version in the process as well.
Package was imported, but never built and it's now retired. Closing.