https://bugzilla.redhat.com/show_bug.cgi?id=1773720
Brandon Perkins <bperkins(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(bperkins(a)redhat.c |
|om) |
--- Comment #10 from Brandon Perkins <bperkins(a)redhat.com> ---
(In reply to Ryan O'Hara from comment #9)
[ ]: License file installed when any subpackage combination is installed.
- The license is definitely installed with the regular rpm and/or the -devel
package. Does this requirement also apply to debuginfo and debugsource
packages? I'm going to assume not.
So, this is a great question that, AFAICT has not been resolved:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
and I don't get clarity from:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_L...
or
https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/
I would say that we defer to the auto-generation done by the macros which
appears to not include it.
[ ]: Package must own all directories that it creates.
Note: Directories without known owners: /etc/logrotate.d
- I don't think this is optional. Having the "suggests" line is the spec
seems ok, but this package is creating a directory with no owner.
The /etc/logrotate.d directory is owned by the 'logrotate' package:
$ rpm -qf /etc/logrotate.d
logrotate-3.15.1-1.fc31.x86_64
This issue is properly satisfied by the logrotate 'Suggests' in the RPM:
$ grep ^Suggests: SPECS/golang-github-haproxytech-dataplaneapi.spec
Suggests: logrotate
$ rpm -qp --suggests
RPMS/golang-github-haproxytech-dataplaneapi-1.2.4-5.fc31.x86_64.rpm
logrotate
To me, it's better to have a possible orphan directory than to have this
package become the owner of the directory. And, we certainly wouldn't be the
first to go down this path. Quick query shows me:
[bperkins@bperkins haproxytech]$ dnf repoquery --queryformat="%{NAME}"
--whatsuggests logrotate
mariadb-server
plymouth
However, many more do the ownership thing (which just seems wrong to me):
[bperkins@bperkins haproxytech]$ dnf repoquery --queryformat="%{NAME}"
--whatprovides /etc/logrotate.d
bes
copr-dist-git
gap-pkg-scscp
gerbera
kdm-settings
lightdm
logrotate
macromilter
openqa
ppp
psad
samba-common
sssd-common
yast2-filesystem
Or, we could go down what I *really* think is wrong and just ignore the issue
completely (which is by far the most popular path).
I'm personally inclined to do what I did, but I can certainly change it.
[ ]: Package does not own files or directories owned by other
packages.
Note: Dirs in package are owned also by:
- This seems like an issue with all Go modules, as mentioned above.
[ ]: Fully versioned dependency in subpackages if applicable.
Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in golang-
github-haproxytech-dataplaneapi-devel
- Can we do this? I know upstream is versioning the releases of the various
dataplaneapi components. I'm not sure if this works for go packages.
Using the %gopkg macro, I don't see how this could be accomplished. This
really doesn't seem like a critical requirement to me.
Rpmlint
-------
Checking: golang-github-haproxytech-dataplaneapi-1.2.4-6.fc33.x86_64.rpm
golang-github-haproxytech-dataplaneapi-devel-1.2.4-6.fc33.noarch.rpm
golang-github-haproxytech-dataplaneapi-debuginfo-1.2.4-6.fc33.x86_64.rpm
golang-github-haproxytech-dataplaneapi-debugsource-1.2.4-6.fc33.x86_64.rpm
golang-github-haproxytech-dataplaneapi-1.2.4-6.fc33.src.rpm
golang-github-haproxytech-dataplaneapi-devel.noarch: W: hidden-file-or-dir
/usr/share/gocode/src/github.com/haproxytech/dataplaneapi/.goipath
golang-github-haproxytech-dataplaneapi-debugsource.x86_64: E:
description-line-too-long C This package provides debug sources for package
golang-github-haproxytech-dataplaneapi.
5 packages and 0 specfiles checked; 1 errors, 1 warnings.
Rpmlint (debuginfo)
-------------------
Checking:
golang-github-haproxytech-dataplaneapi-debuginfo-1.2.4-6.fc33.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Rpmlint (installed packages)
----------------------------
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
golang-github-haproxytech-dataplaneapi.x86_64: W: invalid-url URL:
https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] Name
or service not known>
golang-github-haproxytech-dataplaneapi-debugsource.x86_64: E:
description-line-too-long C This package provides debug sources for package
golang-github-haproxytech-dataplaneapi.
golang-github-haproxytech-dataplaneapi-debugsource.x86_64: W: invalid-url
URL:
https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2]
Name or service not known>
golang-github-haproxytech-dataplaneapi-debuginfo.x86_64: W: invalid-url URL:
https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] Name
or service not known>
golang-github-haproxytech-dataplaneapi-devel.noarch: W: invalid-url URL:
https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] Name
or service not known>
golang-github-haproxytech-dataplaneapi-devel.noarch: W: hidden-file-or-dir
/usr/share/gocode/src/github.com/haproxytech/dataplaneapi/.goipath
4 packages and 0 specfiles checked; 1 errors, 5 warnings.
- I'd love to fix the URL issue since we've seen that in every package we've
reviewed for the dataplaneapi effort. Probably more important is the error
regarding the description line is too long.
URL issue can be dealt with by running it semi-manually:
$ sudo mkdir -p /var/lib/mock/fedora-rawhide-x86_64/root/root/.config
$ echo "addFilter(r\"hidden-file-or-dir
/usr/share/gocode/src/github\.com/.*/.*/.goipath$\")" > /tmp/rpmlint.config
$ sudo cp /tmp/rpmlint.config
/var/lib/mock/fedora-rawhide-x86_64/root/root/.config/rpmlint
$ LANG=C.utf8 mock -q -r fedora-rawhide-x86_64 --no-bootstrap-chroot
--no-cleanup-after --no-clean --enable-network --chroot -- rpmlint -f
/root/.config/rpmlint golang-github-haproxytech-dataplaneapi
golang-github-haproxytech-dataplaneapi-debuginfo
golang-github-haproxytech-dataplaneapi-debugsource
golang-github-haproxytech-dataplaneapi-devel
golang-github-haproxytech-dataplaneapi-debugsource.x86_64: E:
description-line-too-long C This package provides debug sources for package
golang-github-haproxytech-dataplaneapi.
4 packages and 0 specfiles checked; 1 errors, 0 warnings.
However, it does still show the line too long problem.
# rpm -qip
golang-github-haproxytech-dataplaneapi-debugsource-1.2.4-6.fc33.x86_64.rpm
Name : golang-github-haproxytech-dataplaneapi-debugsource
Version : 1.2.4
Release : 6.fc33
Architecture: x86_64
Install Date: (not installed)
Group : Development/Debug
Size : 2785503
License : ASL 2.0
Signature : (none)
Source RPM : golang-github-haproxytech-dataplaneapi-1.2.4-6.fc33.src.rpm
Build Date : Mon 13 Apr 2020 01:20:34 PM CDT
Build Host : wilco
URL :
https://github.com/haproxytech/dataplaneapi
Summary : Debug sources for package
golang-github-haproxytech-dataplaneapi
Description :
This package provides debug sources for package
golang-github-haproxytech-dataplaneapi.
Debug sources are useful when developing applications that use this
package or when debugging this package.
- So that looks too long:
# echo "This package provides debug sources for package
golang-github-haproxytech-dataplaneapi." | wc -c
88
- Can we shorten this? rpmlint sees this as an error.
Because of using the %gopkg macro, we're kind of stuck with what it creates.
Outside of modifying the macro (which is a non-starter), the only thing that
could be done would be to shorten the package name, which is also a
non-starter. I think it's an error we just have to live with. Unless you have
any other thoughts.
--
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