Bug 226365 - Merge Review: redhat-rpm-config
Summary: Merge Review: redhat-rpm-config
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config
Version: 23
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Fedora Packaging Toolset Team
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-31 20:49 UTC by Nobody's working on this, feel free to take it
Modified: 2016-11-07 14:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-11-07 14:02:39 UTC
Type: ---

Attachments (Terms of Use)

Description Nobody's working on this, feel free to take it 2007-01-31 20:49:24 UTC
Fedora Merge Review: redhat-rpm-config

Initial Owner: jcm@redhat.com

Comment 1 Patrice Dumas 2007-11-27 00:15:07 UTC
Is the archive only present in the srpm? Couldn't there be a
better place for it, to allow for easier modifications?

Shouldn't the references to Red Hat be removed? The reference
to Red Hat are in config.guess, though it seems a bit buggy
since the mere presence of the file isn't a necessary condition
for redhat to be vendor. I don't know what is the exact status 
of that file regarding trademark, though:
config.guess:## for Red Hat Linux
config.guess:if test -f /etc/redhat-release ; then
config.guess:    VENDOR=redhat ;

in dist.sh, I think that  /etc/system-release should be used instead.

In macros there is
%_vendor         redhat

# Use these macros to differentiate between RH and other KMP implementation(s).
redhat_kernel_module_package     1
I believe this one is right, but redhat is not really redhat here,
it could be anything else.

In the spec file there are also references to Red Hat, it seems
to me that they should be changed to something more neutral, like

Now the %_vendor definition is right, and this itself seems a good
reason to me to keep the package name and the directory name. What
do you think about it? In any case if there are trademark issues,
it would be nice to be easily able to change redhat to something
else at a specific place only, such that this package can easily
be reused.

Buildroot is not in the accepted ones.

Summary should not end with a dot.

Comment 2 Susi Lehtola 2009-03-28 18:26:56 UTC
Taking on review.

Comment 3 Susi Lehtola 2009-03-28 18:42:11 UTC
rpmlint output:
redhat-rpm-config.noarch: W: no-documentation
redhat-rpm-config.noarch: E: non-executable-script /usr/lib/rpm/redhat/find-provides.d/firmware.prov 0644
redhat-rpm-config.noarch: E: non-executable-script /usr/lib/rpm/redhat/find-provides.d/modalias.prov 0644
redhat-rpm-config.noarch: W: summary-ended-with-dot Red Hat specific rpm configuration files.
redhat-rpm-config.noarch: W: no-url-tag
redhat-rpm-config.noarch: E: only-non-binary-in-usr-lib
redhat-rpm-config.src:121: W: macro-in-%changelog name
redhat-rpm-config.src:265: W: macro-in-%changelog configure
redhat-rpm-config.src:274: W: macro-in-%changelog __spec_install_post
redhat-rpm-config.src: E: no-cleaning-of-buildroot %install
redhat-rpm-config.src: W: no-%build-section
redhat-rpm-config.src: W: summary-ended-with-dot Red Hat specific rpm configuration files.
redhat-rpm-config.src: W: no-url-tag
2 packages and 0 specfiles checked; 4 errors, 9 warnings.

- Fix the macros in changelog (should be %%name instead of %name etc).

- Clean buildroot before install.

- Add disclaimer from http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream to spec file.

- Remove dot from summary and set executable flags on scripts.

- Drop use of %{_prefix}.

- Change buildroot to
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)

MUST: The spec file for the package is legible and macros are used consistently. 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}. OK
MUST: The package must be licensed with a Fedora approved license and meet the  Licensing Guidelines. OK

MUST: The License field in the package spec file must match the actual license. NEEDSFIX
- Since we are upstream it should be no problem to get the license specified and the license files included in the package.

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. NEEDSFIX

MUST: The package MUST successfully compile and build into binary rpms. OK
MUST: The spec file MUST handle locales properly. OK
MUST: Optflags are used and time stamps preserved. OK
MUST: Packages containing shared library files must call ldconfig. OK
MUST: A package must own all directories that it creates or require the package that owns the directory. OK
MUST: Files only listed once in %files listings. OK
MUST: Permissions on files must be set properly. OK
MUST: Clean section exists. OK
MUST: Large documentation files must go in a -doc subpackage. OK
MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK
MUST: Header files must be in a -devel package. OK
MUST: Static libraries must be in a -static package. OK
MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. OK
MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. OK
MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. OK
MUST: Packages does not contain any .la libtool archives. OK
MUST: Desktop files are installed properly. OK
MUST: No file conflicts with other packages and no general names. OK

MUST: Buildroot cleaned before install. NEEDSFIX

SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. NEEDSFIX

SHOULD: %{?dist} tag is used in release. OK
SHOULD: The package builds in mock. OK

Comment 4 Susi Lehtola 2009-04-24 20:36:56 UTC
Please address issues.

Comment 5 Susi Lehtola 2009-06-08 19:05:29 UTC

Comment 6 Jon Masters 2009-06-08 19:16:30 UTC
Oh, I don't seem to be assigned to this properly, but anyway, ok, I'll look.

Comment 7 Susi Lehtola 2009-06-08 19:49:49 UTC
Ugh, you're not supposed to change the assignment; Merge Reviews are like Package Reviews: the reviewer is the assignee, s/he makes critical notes about the package that are dealt with by the maintainer(s).

Well, if getting this done requires you to get the assignment, that's OK with me.

Comment 8 Cole Robinson 2015-02-11 20:38:47 UTC
Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:


If you don't know what merge reviews are about, please see:


How to handle this bug is left to the discretion of the package maintainer.

Comment 9 Jan Kurik 2015-07-15 15:24:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 10 Panu Matilainen 2016-11-07 14:02:39 UTC
Hasn't gotten done in nine years, ain't gonna happen now. There's not much in common between the starting point and current situation anyway.

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