Red Hat Bugzilla – Bug 454329
Review Request: PolicyKit-olpc - OLPC-specific PolicyKit overrides
Last modified: 2013-03-13 01:43:29 EDT
Spec URL: http://dev.laptop.org/~dsd/PolicyKit-olpc/
SRPM URL: http://dev.laptop.org/~dsd/PolicyKit-olpc/PolicyKit-olpc-1.0-1.fc9.src.rpm
Software for the XO laptop requires some modification to the default policies
installed by certain applications. This package provides OLPC-specific
policy overrides. See http://dev.laptop.org/ticket/7350
This is my first package, and I am seeking a sponsor. Maybe Dennis Gilmore ;-)
Spec URL: http://dev.laptop.org/~dsd/PolicyKit-olpc/PolicyKit-olpc.spec
I can't verify functionality but it seems better to add a package dependency
instead of the file dependency on /var/lib/PolicyKit-public. Afaik, permissive
licenses like MIT or revised 2 clause BSD licenses are considered better from
the legal standpoint as opposed to public domain due to presence of disclaimers.
You might want to consider that.
Thanks for the feedback! I changed it to MIT and uploaded v1.2.
We already have the appropriate package-specific depends: PolicyKit
We additionally depend on the directory because PolicyKit upstream told us the location where these files are stored may change in future. This dependency will make sure that we notice if/when this change happens.
Sorry for the delay. Approved. Please proceed for cvs admin request.
New Package CVS Request
Package Name: PolicyKit-olpc
Short Description: OLPC-specific PolicyKit overrides
Cvsextras Commits: yes
PolicyKit-olpc-1.2-1.fc9 has been submitted as an update for Fedora 9
Thanks for reviewing, we're all done here.
PolicyKit-olpc-1.2-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #2)
> I can't verify functionality but it seems better to add a package dependency
> instead of the file dependency on /var/lib/PolicyKit-public.
IMO this was a really bad idea, because yum runs out of memory on the XO when resolving file based deps.
Does it make sense to add comments to a review done more than six months back? You seem to actually agree with what I said. Don't quite see the point.
I think it does, because I'm referring to a problem you already raised in the review. IMO you should have insisted on following the guidelines here, because they clearly state: "Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin."
Read what I have written very carefully one more time. I am advocating against file based dependencies. What exactly is your beef? Drop the witch hunt digging up old reviews.
(In reply to comment #13)
> Read what I have written very carefully one more time. I am advocating against
> file based dependencies.
I *did* read what you wrote and I fully understand we both agree on the topic. However I don't understand why you approved the package with the file based dep.
> What exactly is your beef? Drop the witch hunt digging up old reviews.
I want to enhance the review quality in Fedora and IMHO these three word reviews ("Looks good, approved") should be forbidden.
The idea of looking into six month old reviews of only mine because of your desire to improve quality does not sound very convincing.
You might not know this but Daniel Drake works for OLPC. If there are any performance issues with the choice of a file based dependency, he would fixed it by now. There are no need force a common sense recommendation in the guidelines into a mandatory check point and file based dependencies are NOT forbidden at all. All the guidelines have been followed and the review quality is fine. If you disagree and want to dig up old reviews, go ahead and take it up to FESCo. Until that point, I have nothing further to say on this topic.
(In reply to comment #15)
> The idea of looking into six month old reviews of only mine because of your
> desire to improve quality does not sound very convincing.
Please don't take this personally, I'm not picking on you. I'm definitely not only doing this with your reviews, but also with others whenever I stumble upon something that IMO should have been fixed in the review (e. g. bug 502920).
> You might not know this but Daniel Drake works for OLPC.
Rahul, I *can* read and I do know Daniel from various OLPC-related IRC conversations.
> All the guidelines have been followed and the review quality
> is fine.
It should be obvious for others what you have checked and what not.
Yes, it should be obvious and until the point you find a actual problem, there is nothing to discuss.