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: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 ------- Additional Comments From paul@xxxxxxxxxxxx 2006-02-23 02:59 EST ------- (In reply to comment #6) > Or you could just get rid of your silly rules which discriminate against > packages for no real reason. > > The license is clearly posted in the spec file and in every .c file in the > package. The correct procedure for checking the license of a package on an > RPM-based system is "rpm -q --qf '%{LICENSE}\n' <package>". If that works and > returns a standard response ("GPL," "BSD," "MIT," or similar), there should be > no problem. The point of the rule is to ensure that the license tag in the RPM matches the actual license of the upstream package; that's something the reviewer needs to check. IMHO the presence of the license in the source files itself satisfies the "text included" requirement and there's no need for a separate LICENSE file. > Furthermore, the following requirements are just stupid and demonstrate either > pointless fascism on the part of your policy makers or flaws in the design of > your build system: > > > - BuildRoot should be > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > - The BuildRoot must be cleaned at the beginning of %install > > The build system, not the individual RPM's, should ensure that the buildroot > path is unique and clean prior to invoking rpmbuild. Ideally yes, but rpm doesn't do this by default so it has to be done in each package. Even if rpm was changed to do this automatically, packages desiring compatibility with older distributions would still need to clean the buildroot themselves. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
