https://bugzilla.redhat.com/show_bug.cgi?id=1290342 --- Comment #15 from Nicolas Chauvet (kwizart) <kwizart@xxxxxxxxx> --- (In reply to gil cattaneo from comment #14) > (In reply to Nicolas Chauvet (kwizart) from comment #13) > > (In reply to gil cattaneo from comment #10) > > > > > > - You are missing a "-" between email and package EVR in changelog. rpmlint > > > > haven't found it and I don't expect it's a hard requirement. But at least > > > > that the format used by the rpmdev-bumpspec tool > > > > > > I dont want use "-" in my spec file, and i am not interested to use that tool > > > > It's a weird answer. I wouldn't have expected it. > > The problem is that other maintainers and provenpackager will use theses > > tools, or even use parser that may break if the "-" isn't found. > > Above all it's improving readability. > > NOT is a problem, this is because the people you've indicated you have no > problems to make changes in my spec files. and I repeat I am not interested > just about aesthetics without any functionality I'm afraid you don't consider readability as the feature. There is something weird reading most of your spec changelogs. It makes eyes bleeding because something is missing, until one discover what it is. > > > > - What the point to use /usr/bin/perl over perl (as package) directly ? or > > > > at least the appropriate macro ? > > > > > > I need only the binary for change the build scripts ... > > okay, but %{_bindir} should be used here why not using the macro ? > > Also I don't think perl packaging will change it's packaging scheme not to > > have the perl binary in the main perl package. > Done > > That been said, I would use sed (that is in the default buildroot) instead > > to avoid a dependency on perl (that is no more in the default buildroot). > Not in my spec file, unless it is forbidden to use in some guideline https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_spec_files Given that perl isn't in the default buildroot anymore, it will simplify the dependency graph. If you can show me a rationale argument for both issues, I'm okay to approve the package. Alternative is that I will resign from review and you will find a new reviewer. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx