[Bug 1321] Review request: libva-freeworld - Video Acceleration (VA) API for Linux

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=1321





--- Comment #7 from Hans de Goede <j.w.r.degoede at hhs.nl>  2010-07-16 11:38:19 ---
Good:
- rpmlint checks return:
libva-freeworld.x86_64: W: self-obsoletion libva < 0.31.0.1.sds130 obsoletes
libva = 1:0.31.0-1.sds13.fc13
libva-freeworld.x86_64: W: no-manual-page-for-binary vainfo
libva-freeworld-devel.x86_64: W: self-obsoletion libva-devel < 0.31.0.1.sds130
obsoletes libva-devel = 1:0.31.0-1.sds13.fc13
libva-freeworld-devel.x86_64: W: no-documentation
libva-freeworld-utils.x86_64: W: self-obsoletion libva-utils < 0.31.0.1.sds130
obsoletes libva-utils = 1:0.31.0-1.sds13.fc13
libva-freeworld-utils.x86_64: W: no-documentation
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_h264encode
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_10
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary mpeg2vldemo
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_11
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary putsurface
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_05
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_04
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_07
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_06
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_01
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_03
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_02
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_09
libva-freeworld-utils.x86_64: W: no-manual-page-for-binary libva_test_08
libva-freeworld.src:58: W: macro-in-comment %{_includedir}
libva-freeworld.src:23: W: mixed-use-of-spaces-and-tabs (spaces: line 23, tab:
line 1)
- package meets naming guidelines
- package meets packaging guidelines
- license (MIT) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file
- devel package ok
- no .la files
- post/postun ldconfig ok
- devel requires base package n-v-r 

Needs work:
- Hmm, I had not thought about the need for an epoch in the virtual provides
  / obsoletes. I can understand that you want to keep a clean upgrade path from
  3th party repositories already carying this. In that case I would prefer to
  stick with the previous versioning scheme until a new upstream release is 
  made (sorry about this).

- rpmlint:
libva-freeworld.x86_64: W: self-obsoletion libva < 0.31.0.1.sds130 obsoletes
libva = 1:0.31.0-1.sds13.fc13
libva-freeworld-devel.x86_64: W: self-obsoletion libva-devel < 0.31.0.1.sds130
obsoletes libva-devel = 1:0.31.0-1.sds13.fc13
libva-freeworld-utils.x86_64: W: self-obsoletion libva-utils < 0.31.0.1.sds130
obsoletes libva-utils = 1:0.31.0-1.sds13.fc13

I guess rpmlint wants to see an explicit epoch 0 in the obsoletes, but this
does not matter if we switch back to the old versioning screen.

-rpmlint:
libva-freeworld.src:23: W: mixed-use-of-spaces-and-tabs (spaces: line 23, tab:
line 1)


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.