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

[Bug 182175] Review Request: libast - handy routines and drop-in substitutes for some good-but-non-portable functions (needed by eterm)



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


mej eterm org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mej eterm org




------- Additional Comments From mej eterm org  2006-02-22 23:56 EST -------
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.

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.


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


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