[Bug 688315] Review Request: rubygem-little-plugger - gem based plugin management
bugzilla at redhat.com
bugzilla at redhat.com
Thu Jul 7 14:49:22 UTC 2011
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=688315
--- Comment #6 from Chris Lalancette <clalance at redhat.com> 2011-07-07 10:49:21 EDT ---
(In reply to comment #4)
> [ OK ] MUST: rpmlint must be run on every package
> [ OK ] MUST: The package must be named according to the Package Naming
> Guidelines
> [ OK ] MUST: The spec file name must match the base package %{name} [...]
> [ ?? ] MUST: The package must meet the Packaging Guidelines
>
> Possible fail, use of %define, guidelines say use of %global is preferred. (Did
> gem2rpm do this?) Ruby packaging guidelines seem to be not applicable to gems;
> is that correct?
Right, I didn't know about that guideline. I'll update it. And yes, gem2rpm
did do the %define. I think we really need to update gem2rpm to conform to
some of these new requirements, but -ENOTIME.
>
> [ OK ] MUST: The package must be licensed with a Fedora approved license
> and meet the Licensing Guidelines
> [ FAIL ] MUST: The License field in the package spec file must match the
> actual license
>
> Spec says GPLV2+ or Ruby. README.rdoc in the gem->data.tar.gz says MIT.
Yep, good catch. Fixed.
>
> N.B. file timestamps in the gem (tar file) and the embedded data.tar.gz are
> 1969-12-31. Tar on my f14 box is silent, tar on my f15 box whines.
Hm, odd. On my system, both the SRPM and the gem file both have valid
timestamps. I wonder what the deal there is.
>
> [ OK ] MUST: 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 must be included in %doc
> [ OK ] MUST: The spec file must be written in American English.
> [ OK ] MUST: The spec file for the package MUST be legible.
> [ OK ] MUST: The sources used to build the package must match the upstream
> source, as provided in the spec URL. Reviewers should use md5sum for
> this task. If no upstream URL can be specified for this package,
> please see the Source URL Guidelines for how to deal with this.
> [ OK ] MUST: The package MUST successfully compile and build into binary
> rpms on at least one primary architecture
> [ N/A ] MUST: If the package does not successfully compile, build or work on
> an architecture, then those architectures should be listed in the
> spec in ExcludeArch. Each architecture listed in ExcludeArch MUST
> have a bug filed in bugzilla, describing the reason that the package
> does not compile/build/work on that architecture. The bug number MUST
> be placed in a comment, next to the corresponding ExcludeArch line
> [ OK ] MUST: All build dependencies must be listed in BuildRequires, except
> for any that are listed in the exceptions section of the Packaging
> Guidelines ; inclusion of those as BuildRequires is optional. Apply
> common sense.
> [ OK ] MUST: The spec file MUST handle locales properly. This is done by
> using the %find_lang macro. Using %{_datadir}/locale/* is strictly
> forbidden
> [ N/A ] MUST: Every binary RPM package (or subpackage) which stores shared
> library files (not just symlinks) in any of the dynamic linker's
> default paths, must call ldconfig in %post and %postun.
> [ N/A ] MUST: If the package is designed to be relocatable, the packager must
> state this fact in the request for review, along with the
> rationalization for relocation of that specific package. Without
> this, use of Prefix: /usr is considered a blocker.
> [ OK ] MUST: A package must own all directories that it creates. If it does
> not create a directory that it uses, then it should require a package
> which does create that directory.
> [ OK ] MUST: A package must not contain any duplicate files in the %files
> listing.
> [ FAIL ] MUST: Each package must consistently use macros.
>
> use %{_mkdir}, %{_cp}, and %{_rm} instead of mkdir, cp, and rm respectively.
> (Is this another gem2rpm bug?)
Hm. https://fedoraproject.org/wiki/Packaging:Guidelines#Macros says:
"Macro forms of system executables SHOULD NOT be used except when there is a
need to allow the location of those executables to be configurable. For
example, rm should be used in preference to %{__rm}, but %{__python} is
acceptable."
I left the rm, mkdir, and cp as-is based on that.
>
> [ OK ] MUST: The package must contain code, or permissable content.
> [ OK ] MUST: Large documentation files must go in a -doc subpackage. (The
> definition of large is left up to the packager's best judgement, but
> is not restricted to size. Large can refer to either size or
> quantity).
> [ OK ] MUST: If a package includes something as %doc, it must not affect the
> runtime of the application. To summarize: If it is in %doc, the
> program must run properly if it is not present.
> [ N/A ] MUST: Header files must be in a -devel package.
> [ N/A ] MUST: Static libraries must be in a -static package.
> [ N/A ] MUST: Packages containing pkgconfig(.pc) files must 'Requires:
> pkgconfig' (for directory ownership and usability).
> [ N/A ] MUST: If a package contains library files with a suffix (e.g.
> libfoo.so.1.1), then library files that end in .so (without suffix)
> must go in a -devel package.
> [ N/A ] MUST: In the vast majority of cases, devel packages must require the
> base package using a fully versioned dependency: Requires: %{name} =
> %{version}-%{release}
> [ N/A ] MUST: Packages must NOT contain any .la libtool archives, these must
> be removed in the spec if they are built.
> [ N/A ] MUST: Packages containing GUI applications must include a
> %{name}.desktop file, and that file must be properly installed with
> desktop-file-install in the %install section. If you feel that your
> packaged GUI application does not need a .desktop file, you must put
> a comment in the spec file with your explanation.
> [ OK ] MUST: Packages must not own files or directories already owned by
> other packages. The rule of thumb here is that the first package to
> be installed should own the files or directories that other packages
> may rely upon. This means, for example, that no package in Fedora
> should ever share ownership with any of the files or directories
> owned by the filesystem or man package. If you feel that you have a
> good reason to own a file or directory that another package owns,
> then please present that at package review time.
> [ OK ] MUST: At the beginning of %install, each package MUST run rm -rf
> %{buildroot} (or $RPM_BUILD_ROOT).
> [ OK ] MUST: All filenames in rpm packages must be valid UTF-8.
> [ ? ] SHOULD query upstream to include it.
> [ N/A ] SHOULD: The description and summary sections in the package spec file
> should contain translations for supported Non-English languages, if
> available.
> [ OK ] SHOULD: The reviewer should test that the package builds in mock.
>
> x86-64 and i386 tested.
>
> [ SKIP ] SHOULD: The package should compile and build into binary rpms on all
> supported architectures.
> [ SKIP ] SHOULD: The reviewer should test that the package functions as
> described. A package should not segfault instead of running, for
> example.
> [ N/A ] SHOULD: If scriptlets are used, those scriptlets must be sane. This is
> vague, and left up to the reviewers judgement to determine sanity.
> [ N/A ] SHOULD: Usually, subpackages other than devel should require the base
> package using a fully versioned dependency.
> [ N/A ] SHOULD: The placement of pkgconfig(.pc) files depends on their
> usecase, and this is usually for development purposes, so should be
> placed in a -devel pkg. A reasonable exception is that the main pkg
> itself is a devel tool not installed in a user runtime, e.g. gcc or
> gdb.
> [ N/A ] SHOULD: If the package has file dependencies outside of /etc, /bin,
> /sbin, /usr/bin, or /usr/sbin consider requiring the package which
> provides the file instead of the file itself.
> [ ] SHOULD: your package should contain man pages for binaries/scripts. If
> it doesn't, work with upstream to add them where they make sense.[34]
I think the rest is fine. I've uploaded new versions of the package to the
same place as the initial comment. Can you take a look? Once you are
satisfied, the next step would be to change the fedora-review flag to +, but it
seems like you are having trouble doing that. I would recommend emailing the
bugzilla maintainers (bugzilla-owner at redhat.com, I think) to see what the deal
is.
Thanks for the review,
Chris Lalancette
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the package-review
mailing list