Well, I don't know this package at all,
however, it seems that 0.5.16 is released.

So would you update this package?

ping?

* Fri Nov 24 2006 Enrico Scholz <enrico.scholz.de> - 0.5.16-1
- updated to 0.5.16; handling of libgsf linking of main library needs
  some rethinking: adding such a heavy dependency just to workaround a
  problem in one plugin is not acceptably

Okay, I will check this later.

Well, three questions/issues.

* Is /usr/bin/extract work with no plugins? I think libextractor should
  depend at least on libextractor-plugins-base.

* Please use the more specific home URL. I suggest 
  http://gnunet.org/libextractor/

* I think README.debian is not needed.

* Thu Dec 14 2006 Enrico Scholz <enrico.scholz.de> - 0.5.16-2
- added a requirement for plugins to the main package
- do not ship README.debian anymore
- improved URL:

http://ensc.de/fedora/libextractor/

Well,

* For main package:
----------------------------------
Requires:	plugin(%name)
----------------------------------
  What I meant was main package (libextract) should require
  at least base plugin package (libextract-plugins-base).
  plugin(%name) is not provided by libextract-plugins-base and
  then currently extra plugin package is needed for main (libextract)
  package.

* For fake plugin package (libextract-plugins)
  Dependency for pdf plugin (libextract-plugins-pdf) is missing.

> * For main package:
> ----------------------------------
> Requires:	plugin(%name)
> ----------------------------------
>   What I meant was main package (libextract) should require at least
>   base plugin package (libextract-plugins-base).  plugin(%name) is
>   not provided by libextract-plugins-base and then currently extra
>   plugin package is needed for main (libextract) package.

I do not think so:

1. libextract works without plugins too. But because output is very
   limited in this case, you can say that plugins are highly recommended
   (*not* required)

   Nevertheless, because 'highly recommended' can not be expressed
   with RPM, I accept that some 'Requires:' should be used.


2. libextract does not require the -plugins-base plugins but works
   e.g. with the thumbnail plugin when e.g. a collection of images
   shall be indexed


Therefore, I use

| Requires: plugin(%name)

which satisfies 1. and allows users to install only the really needed
plugins (2.).



> * For fake plugin package (libextract-plugins)
>   Dependency for pdf plugin (libextract-plugins-pdf) is missing.

ok; I will add this dependency (but do not ship a new package for this
change).

Well, 

(In reply to comment #8)
> > * For main package:
> > ----------------------------------
> > Requires:	plugin(%name)
> > ----------------------------------
> >   What I meant was main package (libextract) should require at least
> >   base plugin package (libextract-plugins-base).  

> I do not think so:
> 
> 1. libextract works without plugins too. But because output is very
>    limited in this case, you can say that plugins are highly recommended
>    (*not* required)
> 
> 2. libextract does not require the -plugins-base plugins but works
>    e.g. with the thumbnail plugin when e.g. a collection of images
>    shall be indexed
> 
> Therefore, I use
> Requires: plugin(%name)
> 
> which satisfies 1. and allows users to install only the really needed
> plugins (2.).

My biggest worry is that when libextractor requires
plugin(libextractor), I cannot tell in advance which package this
Requires actually pulls to satisfy this dependency
because plugin(libextractor) is provided more than one package.

... For me, this always pulls a same package:
-----------------------------------------------------
[root@localhost i386]# yum --disablerepo=\*debug\* --disablerepo=\*dries\*
--disablerepo=\*freshrpms\* install libextractor
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package libextractor.i386 0:0.5.16-2.fc7 set to be updated
--> Running transaction check
--> Processing Dependency: plugin(libextractor) for package: libextractor
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package libextractor-plugins-pdf.i386 0:0.5.16-2.fc7 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 libextractor            i386       0.5.16-2.fc7     LOCAL              70 k
Installing for dependencies:
 libextractor-plugins-pdf  i386       0.5.16-2.fc7     LOCAL             131 k

Transaction Summary
=============================================================================
Install      2 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 201 k
Is this ok [y/N]: N
Exiting on user Command
Complete!
-----------------------------------------------------

however, 
* I am not sure if yum always pulls -pdf package for everyone
* and I am not sure if pulling -pdf package is what you expect
  if yum always pulls -pdf package.

If there is no "best" idea as of what plugins main package should
require for a minimal usage, you may want to remove plugin requirement
as before. My idea is requiring -plugins-base package is 
convenient for libextractor users. How do you think?

* I think, it is a bug in yum. It should fail on such ambiguities instead of
  using the short-name-wins method

* I see the following two solutions:

  1. abuse yum's (mis)behavior and add a

     | Provides: plugin(%name)

     to 'libextractor-plugins' package. This will pull in all available
     plugins (because 'libextractor-plugins' is the shortest package name and
     wins therefore).

     This will not address problems with smart or apt.

  2. remove the 'Requires: plugin(%name)' accordingly your suggestion and add a 
     README.fedora which explains that user has to install additional plugin
     packages

I think the latter (No.2) of your suggestion is better
if you feel no reluctance to write README.fedora .

Pulling all plugins is not preferable if this package can
be used without plugins IMO.

* Wed Dec 27 2006 Enrico Scholz <enrico.scholz.de> - 0.5.16-3
- added a README.fedora
- removed the previously added 'Requires: plugin(%name)'
- added the pdf plugin to the requirements of the -plugins subpackage

http://ensc.de/fedora/libextractor/

Well, this package is okay.

      This package (libextractor) is APPROVED by me
--------------------------------------------------

COMMENTS (none of the following two are blockers)
-  I recommend to add your name to README.fedora
-  My opinion is 
--------------------------------------------------
/etc/alternatives/libextractor_thumbnail
/usr/lib/libextractor/plugins/ibextractor-thumbnail.so
--------------------------------------------------
   should be owned as ghost files by -thumbnailgtk and
   -thumbnailqt packages, however, currently no other
   package own /etc/alternatives/* files nor alternate
   link files. How do you think??

NOTES
A. http://fedoraproject.org/wiki/Packaging/Guidelines
= Naming okay
= Legal okay
  - GPL (OSI approved)
  - Documentation included
  - Actually coincide with source code license
  - No patent-related issue
= Filesystem Layout okay
= rpmlint -- not silent, however all can be ignored
= Changelog proper
= Tag okay
= Buildroot okay (although not a format of "recommended")
= Requires - not needed but for ones automatically checked
  by rpmbuild
= BuildRequires - mockbuild okay
= Summary/Description okay
= Documentation - all files which should be included
  are all included actually
= Mockbuild says Fedora specific compilation flags are passed
= No static archives/la files
= No use of local copy of system libraries
= rpm -qa libextractor\* | xargs rpm -ql | xargs /usr/lib/rpm/check-rpaths-worker 
  does not complain
= No config file
= This is not GUI package
= Macros are correctly handled
= No mixed usage of %buildroot <-> $RPM_BUILD_ROOT
= %makeinstall not used
= proper %find_lang usage
= Timestamps okay
= Parallel make intentionally disabled
= Scriptlets: ... okay
  - ldconfig
  - alternatives
= Relocation disabled
= Ownership okay
= Not web apps, /var/www is not used

B. http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
= Source download okay
= md5sum coincide
= No duplicate files description
= %clean section okay
= -doc subpackage not needed
= -devel package okay
= Requires ... as discussed
= BuildRequires okay

( I can see this package imported into FE devel/6/5 and
  I think you can close this bug with CLOSED NEXTRELEASE )

( ping? Again I think this bug can be closed... )

Closing this bug as NEXTRELEASE

Package Change Request
======================
Package Name: libextractor
New Branches: EL-4 EL-5
Owners: sheltren

I'm going to go ahead and branch this as I've seen statements elsewhere that Enrico doesn't wish to be involved with EPEL, but that he's OK with someone branches his packages for EPEL as long as he's not bothered by the process.  If that is not the case, I sincerely apologize.

CVS done.