[Bug 452559] Review Request: zfuzz - Z fuzz - Type-checker and LaTeX style for Z spec language

[bugzilla at redhat.com]

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 dwheeler at dwheeler.com  2008-06-25 20:04 EST -------
In reply to comment #11)

>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'm don't think that's a good idea.  It's not part of any typical
TeX distribution, and the upstream name is "fuzz" not "tex-zfuzz".
Besides, when I contacted upstream, he recommended "zfuzz".
I'd prefer to keep its name as "zfuzz", to make it more likely that
people who know what it is will find it, and to honor upstream request.

>Sure, I was referring to "${CFLAGS:-%optflags}", here $CFLAGS cannot be
>defined and if they were they should be overwritten anyway.

Oh, _that's_ what you meant!  You mean use:
  make CFLAGS="%{optflags}"

Okay, I'll do that.

>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.

Ok, shortened.

>The BuildConflict is not right. You should arrange for things to 
>build right with or without zfuzz installed.

Ok, done.

> 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.

The point was to justify some decisions for people reading the .spec
file, not for end-users.  I rewrote/shortened the text
to (hopefully) make that clearer.

> 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).

I agree with the problems of using the date.
But as you noted, putting it in the release has its own problems.
Upstream uses a date as the version number and is unlikely to change, so
it seemed reasonable to be consistent with upstream.
Is this critically important?



-- 
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.