Hide Forgot
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/.
probably the icd.
hmm though maybe filesystem
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?
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.
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.
(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.
I created a review request in bug 1001958 for opencl-filesystem which currently only own %{_sysconfdir}/OpenCL - but maybe other paths in future.
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
opencl-filesystem-1.0-1.fc19 has been pushed to the Fedora 19 testing repository.
opencl-filesystem-1.0-1.fc19, pocl-0.8-7.fc19 has been pushed to the Fedora 19 testing repository.
opencl-filesystem-1.0-1.fc19, pocl-0.8-7.fc19 has been pushed to the Fedora 19 stable repository.
pocl-0.8-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/pocl-0.8-7.fc20
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.