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=510734 --- Comment #63 from Pavel Alexeev (aka Pahan-Hubbitus) <pa...@hubbitus.info> 2009-09-03 06:38:13 EDT --- Sorry for delay. As rebuild is requirement to ensure of all binaries born from longtime sources, I done this. And now, I think it good idea also include it. I pack it in subpackage. (In reply to comment #56) > Yes, I've also read this thread. However, it is for sure not wrong to use a > standard tab width. And you would do nearly all other packagers the favor that > they could easily read your spec file with a proper formatting. As you can read no single "all other packagers thing" about it question. > The alternative would be to use just spaces. This would work for everyone and > since there is usually not that many changes in a spec file, it should not > have > that much overhead. Would you agree on this solution? No. Spaces off course always was second solution there, but (IMHO off course) add only mesh. The main reason of it - easy distinguish leaved space in formatting. But, you may wish do it. I think you favorite editor can do it. If not, I wrote little script for that on PHP: http://hubbitus.net.ru/rpm/Fedora11/x11vnc/tab-convert.phps Yo may use it like: $ cat x11vnc.spec | ./tab-convert.php > x11vnc.spec.spaces Or, with power of UNIX-WAY, off course directly in shell f.e: $ cat x11vnc.spec | php -r 'define("TAB_WIDTH", 5);foreach(file("php://stdin") as $l){preg_match_all("/\t+/", $l, $m, PREG_OFFSET_CAPTURE);foreach($m[0] as $mm){$l = str_replace($mm[0],str_repeat(" ", (TAB_WIDTH - ($mm[1] % TAB_WIDTH)) + ( TAB_WIDTH * ( strlen($mm[0]) - 1 ) )), $l);}echo $l;}' > x11vnc.spec.spaces > I think basic indentation is a well-accepted coding standard for nearly all > languages. Especially the inner blocks of constructs like "if () then ... else > ..." or "for" loops should be indented one step more than the surrounding > code. May be you will surprised, but even in one language different projects has own "coding standards". > Here are the missing minor pieces: > > 1. tab width: it would really be nice if you could use either a tab width of 8 > or just convert the spec file to spaces I provide script and command before - with it you can easy convert tabs to spaces if you wish see it. > 2. According to Tom it is not necessary to re-package the tarball. However, he > suggests that the pre-built binaries are deleted in the %prep section. My > suggestion: > - add "find -name '*.jar' -exec rm {} \;" to the end of the %prep section > - add the attached patch to prevent that "make" will enter the "classes" > directory I add string to remove all prebuilt jars and built it again. So, I think there no more to discuss. > 3. Please make sure that the comments in the spec file and the %changelog > entries don't exceed 80 chars per line. Sure, that's also not strictly > required > but nearly all spec files do it this way. ;-) As I remember rpmlint fire warning at one time if string exceeded 79 characters in description. But our days it is not (I especially check). And additionally I have for example Source0 string which is greater. So, it is not impossible in common case. Meantime I truncate some very long lines especially for you. http://hubbitus.net.ru/rpm/Fedora11/x11vnc/x11vnc-0.9.8-11.fc11.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
