Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=226346 --- Comment #7 from Hans de Goede <hdegoede@xxxxxxxxxx> 2010-07-25 14:09:03 EDT --- <The below comment is purely mine and in no way is a comment which I make on behalf of or is endorsed by my employer> First of all let me start with a generic statement about the contents of your last comment. Once I became aware of this merge review I put it on my to do list as I'm a long time Fedora contributor (for many years before I joined Red Hat) and a Fedora Packaging Committee (the Committee which creates the guidelines) member. As such I strongly believe in the review process and that the merge reviews are important. I must say however that I'm very disappointed about your response to my attempt to get python-pyblock into shape. Almost all of your comments are about things which the guidelines either do not specify at all, or clearly allow. Getting such a pedantic response to cleaning up a package, does not motivate me to do further work on this or other merge reviews. I also think that if this is the way how you are handling other merge reviews, you are likely creating unnecessary friction / resistance there as well. (In reply to comment #6) > (In reply to comment #1) > > - The source url disclaimer must be added > > http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream > > This has actually changed since my review. Now we don't allow exceptions of any > kind, so you must create a project homepage at e.g. Fedora Hosted > https://fedorahosted.org/web/. > Yes we are upstream, but this is a very Fedora specific bit of code which is only used by anaconda, which is only used in Fedora. Thus there is no value in creating a website and doing tarbal releases as no other project / person is using python-pyblock (*) or has shown any interest in it. Thus creating a website and a download area would only serve to generate work, quickly get very stale, and serve no useful purpose. AFAIK there is no rule that a project homepage MUST be created, and a thorough search through all guidelines has not found me no such a rule either, quoting from: http://fedoraproject.org/wiki/Packaging/SourceURL "There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX:." Which is exactly which this package is doing. IOW this package is fully following the guidelines as written wrt the source url. *) Unlike for example pyparted the python parted bindings which are also written and maintained by the anaconda team, but which are of interest to others and the anaconda team thus has created a website with a download area for. > ** > > The BuildRoot tag is obsolete. Please modernize to > %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) > or remove it altogether, since it's no longer needed on newer Fedoras. > Yes this is no longer the recommend way of doing things, but it is still allowed, see: http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag Which links to: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#BuildRoot_tag Needless pedantic comment 1. > ** > > rpmlint now stands as: > > python-pyblock.src:12: W: macro-in-comment %{version} > python-pyblock.src:12: W: macro-in-comment %{release} > python-pyblock.src: W: invalid-url Source0: pyblock-0.49.tar.bz2 > python-pyblock.x86_64: W: private-shared-object-provides > /usr/lib64/python2.6/site-packages/block/dmraidmodule.so > dmraidmodule.so.0.49()(64bit) > python-pyblock.x86_64: W: private-shared-object-provides > /usr/lib64/python2.6/site-packages/block/dmmodule.so dmmodule.so.0.49()(64bit) > 3 packages and 0 specfiles checked; 0 errors, 5 warnings. > > You might want to prepend the macros in comments with an additional % to > prevent expansion. These comments are never stored in a generated rpm in anyway and thus are never used in an expanded fashion, so escaping the macros in the comment serves no purpose other then making the comment harder to read. Also in all my 200+ package submissions I've never had this remark before -> Needless pedantic comment 2. > ** > > The build system is IMHO rather unusual for a python module. This probably > explains the lack of an egg that is normally present in Python packages. The guidelines deliberately say absolutely nothing about "allowed" build systems -> Needless pedantic comment 3. > ** > > Note that the package could also be named simply 'pyblock', as this is allowed > per the Naming Guidelines. The current name is allowed and renaming existing packages is a pain, this is not just pedantic it is plain bad advice. Needless pedantic comment 4. > > ** > > (In reply to comment #5) > > Note I've not changed the dir where the documentation > > gets installed as I see no reason for that. > > Now the location of the documentation is rather unorthodox, since the name of > the docdir does not equal that of the package itself. The guidelines do not specify where a package is allowed or not allowed to install documentation (as long as it follows the FHS) -> Needless pedantic comment 5. > > ** > > Otherwise, everything seems to be in condition. Please address the issues > listed above. As explained above I see no need to address any of these non "issues", please approve this merge review. Regards, Hans -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review