[ovirt-devel] vdsm spec file rpmlint

[Dan Kenigsberg]

On Wed, Oct 25, 2017 at 3:21 PM, Nir Soffer <nsoffer at redhat.com> wrote:

> On Wed, Oct 25, 2017 at 9:33 AM Sandro Bonazzola <sbonazzo at redhat.com>
> wrote:
>
>> 2017-10-20 20:05 GMT+02:00 Yaniv Kaul <ykaul at redhat.com>:
>>
>>>
>>>
>>> On Fri, Oct 20, 2017 at 7:56 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>>>
>>>> On Fri, Oct 20, 2017 at 11:37 AM Sandro Bonazzola <sbonazzo at redhat.com>
>>>> wrote:
>>>>
>>>>> Just an heads up we have improvement margin on vdsm spec file quality.
>>>>>
>>>>> [sbonazzo at sbonazzo SPECS]$ rpmlint ./vdsm.spec
>>>>> /var/lib/mock/epel-7-x86_64/result/*rpm
>>>>> vdsm.x86_64: E: explicit-lib-dependency libnl3
>>>>>
>>>>
>>>> What is wrong with this?
>>>>
>>>>
>>>>> vdsm.x86_64: E: explicit-lib-dependency libvirt-client
>>>>> vdsm.x86_64: E: explicit-lib-dependency libvirt-daemon-config-nwfilter
>>>>> vdsm.x86_64: E: explicit-lib-dependency libvirt-lock-sanlock
>>>>> vdsm.x86_64: W: obsolete-not-provided vdsm-infra
>>>>> vdsm.x86_64: E: no-binary
>>>>>
>>>>
>>>> Ha?
>>>>
>>>
>> The package should be of the noarch architecture because it doesn't
>> contain
>> any binaries.
>>
>
> Vdsm has many arch specific requirements, and we have different
> requirements
> on different platforms. Having a arch specific meta package was the
> solution
> suggested by Fedora reviewers about 2 years ago.
>
>
>>
>>
>>
>>>
>>>>
>>>>> vdsm.x86_64: W: conffile-without-noreplace-flag /var/log/vdsm/mom.log
>>>>>
>>>>
>>>> This is not a conf file, we should probably change this
>>>>
>>>>
>>>>> vdsm.x86_64: W: conffile-without-noreplace-flag
>>>>> /var/log/vdsm/supervdsm.log
>>>>> vdsm.x86_64: W: conffile-without-noreplace-flag /var/log/vdsm/vdsm.log
>>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/NetworkManager/conf.d/
>>>>> vdsm.conf
>>>>>
>>>>
>>>> Ha?
>>>>
>>>
>>> Perhaps:
>>> %{_sysconfdir}/NetworkManager/conf.d/vdsm.conf
>>>
>>> should be:
>>> %config(noreplace) %{_sysconfdir}/NetworkManager/conf.d/vdsm.conf
>>>
>>>
>>>
>>>>
>>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/modprobe.d/vdsm-bonding-
>>>>> modprobe.conf
>>>>> vdsm.x86_64: E: non-readable /etc/pki/vdsm/keys/libvirt_password 600
>>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/security/limits.d/99-
>>>>> vdsm.conf
>>>>>
>>>>
>>>> Ha?
>>>>
>>>
>>> Same?
>>>
>>>
>>>>
>>>>
>>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/sudoers.d/50_vdsm
>>>>> vdsm.x86_64: W: systemd-unit-in-etc /etc/systemd/system/libvirtd.
>>>>> service.d/unlimited-core.conf
>>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/systemd/system/libvirtd.
>>>>> service.d/unlimited-core.conf
>>>>> vdsm.x86_64: E: zero-length /etc/vdsm/mom.d/01-parameters.policy
>>>>> vdsm.x86_64: E: wrong-script-interpreter /usr/libexec/vdsm/kvm2ovirt
>>>>> /usr/bin/env python
>>>>>
>>>>
>>>> This used to be the recommended way to write scripts, but it is easy to
>>>> replace with /usr/bin/python2.
>>>>
>>>
>> It should be /usr/bin/python since python is under "alternatives"
>> management
>>
>
> But most of the code is python2 only - we recently update (most) scripts
> to use
> /usr/bin/python2.
>
>
>>
>>
>>
>>>
>>>>
>>>>> vdsm.x86_64: E: wrong-script-interpreter /usr/libexec/vdsm/vm_migrate_hook.py
>>>>> /usr/bin/env python
>>>>> vdsm.x86_64: E: wrong-script-interpreter /usr/share/vdsm/virt/vm_migrate_hook.py
>>>>> /usr/bin/env python
>>>>> vdsm.x86_64: E: non-executable-script /usr/share/vdsm/virt/vm_migrate_hook.py
>>>>> 644 /usr/bin/env python
>>>>> vdsm.x86_64: E: non-standard-dir-perm /var/lib/libvirt/qemu/channels
>>>>> 775
>>>>> vdsm.x86_64: E: non-standard-dir-perm /var/log/core 1777
>>>>> vdsm.x86_64: E: dir-or-file-in-var-run /var/run/vdsm
>>>>>
>>>>
>>>> What is wrong with this?
>>>>
>>>
>>> "/var/run may be a temporary filesystem, so any directories or files
>>> needed there must be created dynamically at boot time."
>>>
>>
> We create these directories in runtime, not sure why we create them also
> during instillation.
>

As of my I0bdc3b1f2be960d536856465979c89ac85bce4a5 (introduced to silence
rpmlint), we no longer do.

I do not recall why do we still have this horrible /var/log/core 1777; I
hoped that with proper integration to ABRT, we can delegate the
responsiblity of collecting core dumps. Irit, do you recall?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20171025/e694f7e3/attachment.html>