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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]