Bug 996953 - Package should own %{_sysconfdir}/OpenCL/vendors/
Package should own %{_sysconfdir}/OpenCL/vendors/
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: opencl-headers (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On: 1001958
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 06:59 EDT by Fabian Deutsch
Modified: 2013-09-29 20:50 EDT (History)
5 users (show)

See Also:
Fixed In Version: pocl-0.8-7.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-10 21:51:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2013-08-14 06:59:21 EDT
Description of problem:
Currently %{_sysconfdir}/OpenCL/vendors/ is not owned, but files residing in it are owned by the different opencl implementations.
Either opencl-headers or ocl-icd should own %{_sysconfdir}/OpenCL/vendors/.
Comment 1 Dave Airlie 2013-08-14 19:35:42 EDT
probably the icd.
Comment 2 Dave Airlie 2013-08-14 19:36:12 EDT
hmm though maybe filesystem
Comment 3 Fabian Deutsch 2013-08-15 02:00:40 EDT
Yes, what is speaking against the icd, is that we can have several icds (even if we currently have only ocl-icd, but we could also package khrono's icd). That's why it can't be owned by the icd.

What speaks against opencl-headers as an owner?


And what is th eprocess of getting it owned by filesystem? I suppose filing a bug against that component?
Comment 4 Fabian Deutsch 2013-08-19 03:42:58 EDT
Ondrej,

have you got an opinion if the path /etc/OpenCL/vendors/ should go into the filesystem package or not? The problem with this path is given in the description.
Comment 5 Ondrej Vasik 2013-08-19 06:52:17 EDT
Well, filesystem package should own the directories which are supposed to exist on the majority of the systems and where multiple packages (usually 3 or more) should normally share the ownership. To prevent that, filesystem owns the directory.

However, if the directory is specific to some specific system usecase, <whatever>-filesystem subpackage/package should exist... e.g. - on my system I have:
kde-filesystem-4-30.1.el6.noarch
mozilla-filesystem-1.9-5.1.el6.i686
filesystem-2.4.39-1.fc16.i386
foomatic-db-filesystem-4.0-7.20091126.el6.noarch
control-center-filesystem-2.28.1-38.el6.i686
mesa-dri-filesystem-9.0-0.7.el6.i686
fontpackages-filesystem-1.41-1.1.el6.noarch
boost-filesystem-1.41.0-11.el6_1.2.i686

My recommendation is to come with some common package for this usecase subgroup and create -filesystem subpackage owning this directory in it. Main filesystem package should be last instance, if there is no such package/field and the usecase is generic enough.
Comment 6 Fabian Deutsch 2013-08-19 08:45:07 EDT
(In reply to Ondrej Vasik from comment #5)
> Well, filesystem package should own the directories which are supposed to
> exist on the majority of the systems and where multiple packages (usually 3
> or more) should normally share the ownership. To prevent that, filesystem
> owns the directory.
> 
> However, if the directory is specific to some specific system usecase,
> <whatever>-filesystem subpackage/package should exist... e.g. - on my system
> I have:
> kde-filesystem-4-30.1.el6.noarch
> mozilla-filesystem-1.9-5.1.el6.i686
> filesystem-2.4.39-1.fc16.i386
> foomatic-db-filesystem-4.0-7.20091126.el6.noarch
> control-center-filesystem-2.28.1-38.el6.i686
> mesa-dri-filesystem-9.0-0.7.el6.i686
> fontpackages-filesystem-1.41-1.1.el6.noarch
> boost-filesystem-1.41.0-11.el6_1.2.i686

I also remember this, now that you say this :)

> My recommendation is to come with some common package for this usecase
> subgroup and create -filesystem subpackage owning this directory in it. Main
> filesystem package should be last instance, if there is no such
> package/field and the usecase is generic enough.

Thanks Ondrej.

Dave, based on Ondrej's suggestion I'd suggest creating a package opencl-filesystem to own the directory.
Comment 7 Fabian Deutsch 2013-08-28 04:11:27 EDT
I created a review request in bug 1001958 for opencl-filesystem which currently only own %{_sysconfdir}/OpenCL - but maybe other paths in future.
Comment 8 Fedora Update System 2013-08-28 09:52:29 EDT
opencl-filesystem-1.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/opencl-filesystem-1.0-1.fc19
Comment 9 Fedora Update System 2013-08-28 17:26:40 EDT
opencl-filesystem-1.0-1.fc19 has been pushed to the Fedora 19 testing repository.
Comment 10 Fedora Update System 2013-09-02 19:30:57 EDT
opencl-filesystem-1.0-1.fc19, pocl-0.8-7.fc19 has been pushed to the Fedora 19 testing repository.
Comment 11 Fedora Update System 2013-09-10 21:51:41 EDT
opencl-filesystem-1.0-1.fc19, pocl-0.8-7.fc19 has been pushed to the Fedora 19 stable repository.
Comment 12 Fedora Update System 2013-09-20 14:56:59 EDT
pocl-0.8-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/pocl-0.8-7.fc20
Comment 13 Fedora Update System 2013-09-29 20:50:01 EDT
pocl-0.8-7.fc20 has been pushed to the Fedora 20 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.