[Bug 226573] Merge Review: xorg-x11-drivers

[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: Merge Review: xorg-x11-drivers


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226573


fedora at leemhuis.info changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fedora at leemhuis.info        |ajackson at redhat.com
                 CC|                            |fedora at leemhuis.info
               Flag|fedora-review?              |fedora-review-




------- Additional Comments From fedora at leemhuis.info  2007-02-03 17:58 EST -------
* I understand the reasons for this package, but it looks like a maintaince
nightmare as somebody needs to make sure this package is updated each time new
drivers get added to the tree. That sucks :-/ -- for example currently there are
at least xorg-x11-drv-amd and xorg-x11-drv-tek4957 available on i386, but not
requires by this (I don't think that's on purpose).

 Suggestions to improve it (just for discussion, I'm unsure what the proper
solution is): ship a script that generates the template for the specfile from
cvs or "yum list" automatically. Or use something similar to the (ugly)trick
that is used in the kmod packages to run a script and include it's output in the
spec file instead of hardcoding the output in the spec -- Then a simple rebuild
should do everything correctly. 

 BTW, in case we stick to the current solution: the script mentioned in the
comment would actually be more useful if one would know what what
"xorg-all-drivers.txt" is or how it can be generated

* Quoting the spec
{{{
# This should match the list of architectures we build the Xorg server for.
# Note the lack of s390{,x}.
ExclusiveArch: %{ix86} x86_64 ia64 ppc ppc64 alpha sparc sparc64
}}} 
 and all those
{{{
%ifarch foo
Requires: bar
%endif
}}}
 It IMHO would me wiser if we'd could use a ExcludeArch and ifnarch those
packages and archs where we now those drivers don't exisit. But that's just my
opinion and a detail and probably not worth the work...

* rpmlint
rpmlint on ./xorg-x11-drivers-7.1-3.i386.rpm
W: xorg-x11-drivers invalid-license MIT/X11
-> MIT would be correct; But I fail what precisely is MIT licensed here...

E: xorg-x11-drivers obsolete-not-provided xorg-x11
-> Why is that obsolete there in any case? 

E: xorg-x11-drivers no-binary
- acceptable in this case

W: xorg-x11-drivers no-documentation
- might be a good idea to just create a small README that exaplains the purpose
of this package (any maybe what might happen if you remove it)

rpmlint on ./xorg-x11-drivers-7.1-3.src.rpm
W: xorg-x11-drivers invalid-license MIT/X11
-> see above

W: xorg-x11-drivers unversioned-explicit-obsoletes xorg-x11
-> if the obsoletes needs to stay better provide one with a version number --
that way we might be able to create a package with that name n the future

* MISC:

 * "URL: http://www.redhat.com", I don't think that's helpful (might even be
confusing), so maybe it should be removed

 * dist-tags are no must, but might be nice to use

* Besides the stuff outlines above:
 package meets naming and packaging guidelines.
 specfile is properly named, is cleanly written and uses macros consistently.
 BuildRequires are proper.
 no shared libraries are present.
 package is not relocatable.
 no duplicates in %files.
 file permissions are appropriate.
 %clean is present.
 %check is present and all tests pass:
        (include the summary from the test suite, if any)
 no scriptlets present.
 code, not content.
 documentation is small, so no -docs subpackage is necessary.
 %docs are not necessary for the proper functioning of the package.
 no headers.
 no pkgconfig files.
 no libtool .la droppings.
 not a GUI app.
 not a web app.
 no open bugs

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