Bug 1467322 - Review Request: manifest-tool - A command line tool used for creating manifest list objects
Review Request: manifest-tool - A command line tool used for creating manifes...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Miller
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-03 08:01 EDT by Josh Boyer
Modified: 2017-07-30 15:50 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-22 23:55:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
admiller: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Josh Boyer 2017-07-03 08:01:55 EDT
Spec URL: https://jwboyer.fedorapeople.org/pub/manifest-tool.spec
SRPM URL: https://jwboyer.fedorapeople.org/pub/manifest-tool-0.6.0-1.gita28af2b.fc25.src.rpm
Description: 

This tool was mainly created for the purpose of viewing, creating, and
pushing the new manifests list object type in the Docker registry. Manifest
lists are defined in the v2.2 image specification and exist mainly for the
purpose of supporting multi-architecture and/or multi-platform images within
a Docker registry.

Fedora Account System Username:
jwboyer
Comment 1 Zbigniew Jędrzejewski-Szmek 2017-07-04 12:58:40 EDT
%global with_bundled is not used anywhere?

> %{!?_licensedir:%global license %doc}
%license is defined everywhere now.

You've got an awful lot of macros that get used at most one time. %provider_tld, really?

Looks OK, but I know nothing about go.
Comment 2 Josh Boyer 2017-07-05 09:50:35 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> %global with_bundled is not used anywhere?
> 
> > %{!?_licensedir:%global license %doc}
> %license is defined everywhere now.

Dropped both.

> You've got an awful lot of macros that get used at most one time.
> %provider_tld, really?

So I copied this infrastructure from the buildah package.  I believe the intention is to allow for different upstream repositories to be used by simply changing the macros rather than redefining every location in the spec.  E.g. one could switch to pulling from a projectatomic.io repository in case there were changes needed before they are merged upstream.  A number of the go-based container tools do this.

> Looks OK, but I know nothing about go.

New version of the spec and SRPM:

Spec URL: https://jwboyer.fedorapeople.org/pub/manifest-tool.spec
SRPM URL: https://jwboyer.fedorapeople.org/pub/manifest-tool-0.6.0-2.gita28af2b.fc25.src.rpm
Comment 3 Zbigniew Jędrzejewski-Szmek 2017-07-05 17:15:13 EDT
> E.g. one could switch to pulling from a projectatomic.io repository in case there were changes needed before they are merged upstream.

I find such excess of macros not very useful — in the unlikely event that the url even changes, search&replace works just as well. And macros make it hard to copy&paste, so I prefer to use macros only for stuff which actually changes, like %_lib, or %version, or %release. Personal preference of course.

> New version of the spec and SRPM:

Unfortunately I cannot volunteer for the review because I lack go knowledge. Sorry!
Comment 4 Josh Boyer 2017-07-05 21:59:24 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> > E.g. one could switch to pulling from a projectatomic.io repository in case there were changes needed before they are merged upstream.
> 
> I find such excess of macros not very useful — in the unlikely event that
> the url even changes, search&replace works just as well. And macros make it
> hard to copy&paste, so I prefer to use macros only for stuff which actually
> changes, like %_lib, or %version, or %release. Personal preference of course.

This url changing actually happens frequently for other go packages.  I don't really care either way though.

> > New version of the spec and SRPM:
> 
> Unfortunately I cannot volunteer for the review because I lack go knowledge.
> Sorry!

Well, thanks for the initial comments anyway.
Comment 5 Adam Miller 2017-07-06 11:47:38 EDT
Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Package installs properly.
  Note: Installation errors (see attachment)
  See: https://fedoraproject.org/wiki/Packaging:Guidelines


===== MUST items =====

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: There is no build directory. Running licensecheck on vanilla
     upstream sources. Licenses found: "Apache (v2.0)", "Unknown or
     generated", "MIT/X11 (BSD like)", "BSD (3 clause)", "BSD (2 clause)",
     "*No copyright* Apache (v2.0)". 795 files have unknown license.
     Detailed output of licensecheck in /home/admiller/reviews/1467322
     -manifest-tool/licensecheck.txt
[-]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[!]: 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.
[-]: 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.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: 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.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 20480 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[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 does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[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 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]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: Uses parallel make %{?_smp_mflags} macro.
[-]: 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).
[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     manifest-tool-debuginfo
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[-]: %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]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     See: http://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint
[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: manifest-tool-0.6.0-2.gita28af2b.fc25.x86_64.rpm
          manifest-tool-debuginfo-0.6.0-2.gita28af2b.fc25.x86_64.rpm
          manifest-tool-0.6.0-2.gita28af2b.fc25.src.rpm
manifest-tool.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti
manifest-tool.x86_64: W: no-manual-page-for-binary manifest-tool
manifest-tool.src: W: spelling-error %description -l en_US multi -> mulch, mufti
3 packages and 0 specfiles checked; 0 errors, 3 warnings.


Requires
--------
manifest-tool (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    libpthread.so.0()(64bit)
    rtld(GNU_HASH)

manifest-tool-debuginfo (rpmlib, GLIBC filtered):



Provides
--------
manifest-tool:
    manifest-tool
    manifest-tool(x86-64)

manifest-tool-debuginfo:
    manifest-tool-debuginfo
    manifest-tool-debuginfo(x86-64)



Source checksums
----------------
https://github.com/estesp/manifest-tool/archive/a28af2b6bf3748859149bf161eb0630e677c3906/manifest-tool-a28af2b.tar.gz :
  CHECKSUM(SHA256) this package     : 9db9b4ec70f9b0c71510cde05139833c192b5649bda2b07af39fbde47aa8d972
  CHECKSUM(SHA256) upstream package : 9db9b4ec70f9b0c71510cde05139833c192b5649bda2b07af39fbde47aa8d972


Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02
Command line :/usr/bin/fedora-review -b 1467322
Buildroot used: fedora-25-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6


ITEMS TO FIX
------------

- All bundled golang libraries need to be listed as 'Provides: bundled(<libname>) = <version>' directives as per https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries

Other than that, the package looks good.
Comment 6 Josh Boyer 2017-07-06 13:21:58 EDT
(In reply to Adam Miller from comment #5)

Thanks for picking up the review!

> ITEMS TO FIX
> ------------
> 
> - All bundled golang libraries need to be listed as 'Provides:
> bundled(<libname>) = <version>' directives as per
> https://fedoraproject.org/wiki/Packaging:
> Guidelines#Bundling_and_Duplication_of_system_libraries
> 
> Other than that, the package looks good.

OK, so I have two questions:

1) Why do e.g. runc, docker, etc not Provide anything they bundle?  Confused there.  I see stuff in -devel, but not in the main packages.

2) An example of a Provide for this package would be:

Provides: bundled(golang(github.com/codegangsta/cli/)) = v1.2.0
Provides: bundled(golang(golang.org/x/net)) = master

correct?
Comment 7 Adam Miller 2017-07-06 18:37:03 EDT
(In reply to Josh Boyer from comment #6)
> (In reply to Adam Miller from comment #5)
> 
> Thanks for picking up the review!
> 
> > ITEMS TO FIX
> > ------------
> > 
> > - All bundled golang libraries need to be listed as 'Provides:
> > bundled(<libname>) = <version>' directives as per
> > https://fedoraproject.org/wiki/Packaging:
> > Guidelines#Bundling_and_Duplication_of_system_libraries
> > 
> > Other than that, the package looks good.
> 
> OK, so I have two questions:
> 
> 1) Why do e.g. runc, docker, etc not Provide anything they bundle?  Confused
> there.  I see stuff in -devel, but not in the main packages.
> 

runc and docker should and if they aren't, they are in violation of the Guidelines, should have bugs filed against them, and should be fixed.


> 2) An example of a Provide for this package would be:
> 
> Provides: bundled(golang(github.com/codegangsta/cli/)) = v1.2.0
> Provides: bundled(golang(golang.org/x/net)) = master
> 
> correct?

The first one looks good pending that is a git tag that can be checked out, the latter however needs to correlate to a commit id or tag.

For an examples, check the OpenShift Origin and/or reg specs:

http://pkgs.fedoraproject.org/cgit/rpms/reg.git/tree/reg.spec
http://pkgs.fedoraproject.org/cgit/rpms/origin.git/tree/origin.spec
Comment 8 Josh Boyer 2017-07-06 21:21:47 EDT
(In reply to Adam Miller from comment #7)
> (In reply to Josh Boyer from comment #6)
> > (In reply to Adam Miller from comment #5)
> > 
> > Thanks for picking up the review!
> > 
> > > ITEMS TO FIX
> > > ------------
> > > 
> > > - All bundled golang libraries need to be listed as 'Provides:
> > > bundled(<libname>) = <version>' directives as per
> > > https://fedoraproject.org/wiki/Packaging:
> > > Guidelines#Bundling_and_Duplication_of_system_libraries
> > > 
> > > Other than that, the package looks good.
> > 
> > OK, so I have two questions:
> > 
> > 1) Why do e.g. runc, docker, etc not Provide anything they bundle?  Confused
> > there.  I see stuff in -devel, but not in the main packages.
> > 
> 
> runc and docker should and if they aren't, they are in violation of the
> Guidelines, should have bugs filed against them, and should be fixed.
> 
> 
> > 2) An example of a Provide for this package would be:
> > 
> > Provides: bundled(golang(github.com/codegangsta/cli/)) = v1.2.0
> > Provides: bundled(golang(golang.org/x/net)) = master
> > 
> > correct?
> 
> The first one looks good pending that is a git tag that can be checked out,
> the latter however needs to correlate to a commit id or tag.

Erm...  any tips on how to determine what commit has been vendored?  The vendor.conf file literally lists "master".


> For an examples, check the OpenShift Origin and/or reg specs:
> 
> http://pkgs.fedoraproject.org/cgit/rpms/reg.git/tree/reg.spec
> http://pkgs.fedoraproject.org/cgit/rpms/origin.git/tree/origin.spec

Yeah, I looked at those to come up with my examples above.  I'll be away from keyboard for a few days, but I'll see what I can come up with and submit a new spec Monday.
Comment 9 Zbigniew Jędrzejewski-Szmek 2017-07-06 22:22:13 EDT
I wouldn't sweat it. In decreasing order of compliance with the guidelines:
- just use a date: Provides: bundled(golang(golang.org/x/net)) = 20170305
   (where the date is the date where the vendorization was done or something)
- just use unversioned provides: Provides: bundled(golang(golang.org/x/net))

(The latter is pretty common, try "rpm -q -a --provides|grep bundled"... The guidelines are well-intentioned, but if it's so hard to find which version exactly is bundled, *and* this is something you'd have to do after every update, I just don't think it's worth your time.)
Comment 10 Adam Miller 2017-07-07 12:01:06 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #9)
> I wouldn't sweat it. In decreasing order of compliance with the guidelines:
> - just use a date: Provides: bundled(golang(golang.org/x/net)) = 20170305
>    (where the date is the date where the vendorization was done or something)
> - just use unversioned provides: Provides: bundled(golang(golang.org/x/net))
> 
> (The latter is pretty common, try "rpm -q -a --provides|grep bundled"... The
> guidelines are well-intentioned, but if it's so hard to find which version
> exactly is bundled, *and* this is something you'd have to do after every
> update, I just don't think it's worth your time.)

Neither of those options is in line with the Guidelines that went through FPC and FESCo for approval, please don't advocate for their use. Neither of those options provide a proper mechanism for auditing. I have opened a ticket with FESCo to determine appropriate action for dealing with all the not versioned bundled entries currently in existence.

https://pagure.io/fesco/issue/1734
Comment 11 Josh Boyer 2017-07-10 12:06:55 EDT
I've added the bundled Provides.  For the bundled versions with explicit tags or commits, I've included those.  For those where I can't tell which upstream is explicitly vendored, I've left the Provides unversioned.  Hopefully that's sufficient in light of the on-going devel discussions.

SPEC: https://jwboyer.fedorapeople.org/pub/manifest-tool.spec
SRPM: https://jwboyer.fedorapeople.org/pub/manifest-tool-0.6.0-3.gita28af2b.fc25.src.rpm
Comment 12 Adam Miller 2017-07-12 18:09:49 EDT
+1 - I'm not going to block this while things are still up in the air on how Fedora as a whole wants to handle this.

APPROVED
Comment 13 Gwyn Ciesla 2017-07-13 08:13:51 EDT
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/manifest-tool
Comment 14 Fedora Update System 2017-07-13 14:52:20 EDT
manifest-tool-0.6.0-3.gita28af2b.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b093304055
Comment 15 Fedora Update System 2017-07-13 14:52:33 EDT
manifest-tool-0.6.0-4.gita28af2b.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bef4cbcf4b
Comment 16 Fedora Update System 2017-07-14 14:50:43 EDT
manifest-tool-0.6.0-4.gita28af2b.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bef4cbcf4b
Comment 17 Fedora Update System 2017-07-14 16:26:45 EDT
manifest-tool-0.6.0-3.gita28af2b.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b093304055
Comment 18 Fedora Update System 2017-07-14 18:55:17 EDT
manifest-tool-0.6.0-3.gita28af2b.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-38e46e1e68
Comment 19 Fedora Update System 2017-07-22 23:55:56 EDT
manifest-tool-0.6.0-3.gita28af2b.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2017-07-23 18:54:39 EDT
manifest-tool-0.6.0-3.gita28af2b.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2017-07-30 15:50:51 EDT
manifest-tool-0.6.0-4.gita28af2b.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

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