Bug 996953

Summary: Package should own %{_sysconfdir}/OpenCL/vendors/
Product: [Fedora] Fedora Reporter: Fabian Deutsch <fabian.deutsch>
Component: opencl-headersAssignee: Dave Airlie <airlied>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, fdeutsch, ovasik, xgl-maint, yaneti
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pocl-0.8-7.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-11 01:51:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1001958    
Bug Blocks:    

Description Fabian Deutsch 2013-08-14 10:59:21 UTC
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 23:35:42 UTC
probably the icd.

Comment 2 Dave Airlie 2013-08-14 23:36:12 UTC
hmm though maybe filesystem

Comment 3 Fabian Deutsch 2013-08-15 06:00:40 UTC
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 07:42:58 UTC
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 10:52:17 UTC
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 12:45:07 UTC
(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 08:11:27 UTC
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 13:52:29 UTC
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 21:26:40 UTC
opencl-filesystem-1.0-1.fc19 has been pushed to the Fedora 19 testing repository.

Comment 10 Fedora Update System 2013-09-02 23:30:57 UTC
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-11 01:51:41 UTC
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 18:56:59 UTC
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-30 00:50:01 UTC
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.