Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: zfuzz - Z fuzz - Type-checker and LaTeX style for Z spec language https://bugzilla.redhat.com/show_bug.cgi?id=452559 ------- Additional Comments From pertusus@xxxxxxx 2008-06-25 18:44 EST ------- (In reply to comment #9) > It's not NEEDED, but it is PERMITTED, so I thought it'd be better to be > explicit. But I don't really care, so I've removed it. It is permitted, but for gcc it is discouraged. > True, but as I commented, I saw little point in doing so. The type-checker and > latex style are meant to be used together, and are combined in upstream anyway. > If that's wrong, they could be split later, but I doubt anyone will want it that > way. Now that I have read the fuzz manual I understand that I was wrong, the fuzz checker needs the latex part. In fact this is a latex package with a syntax checker. It seems to me that it should better be called tex-zfuzz and there is no reason to split it. > >* I think that a patch for adding the DESTDIR would be better than the > > substitution and I hope that upstream would accept it. > > Done. I would hope that too, but I don't control upstream :-). > I _will_ send the patches (and the spec file) to upstream once it's > passed review. Right. > >* I don't think that CFLAGS can be defined when make is launched. > > Sure it can, it works just fine. CFLAGS is just yet another make variable. > Easy test: if you remove the CFLAGS text in this .spec file, the options passed > to gcc change radically. Sure, I was referring to "${CFLAGS:-%optflags}", here $CFLAGS cannot be defined and if they were they should be overwritten anyway. There are still some comments that can be shortened a lot. For example, for the INSTALL file, suffice to say that the license is in the INSTALL file, everybody will understand why it has to be shipped. The BuildConflict is not right. You should arrange for things to build right with or without zfuzz installed. The comment about running mktexlsr is not useful, nor the one describing the manuals. It is in INSTALL which can be read by the user. Regarding the version, I am not sure that using the date is wise. Indeed if the versioning scheme changes, the new version may become newer. I think that using 0 as version and putting the date in the release is better, like Version: 0 Release: 0.X.20070911 This has a disadvantage, namely when release changes, the version doesn't change (similar with development snapshots). (In reply to comment #10) > Okay, hopefully that's the "last one" :-). Not this one... -- 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, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review