Bug 214087 - Review Request: libextractor -- Simple library for keyword extraction
Review Request: libextractor -- Simple library for keyword extraction
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT 221349
  Show dependency treegraph
 
Reported: 2006-11-05 11:53 EST by Enrico Scholz
Modified: 2009-05-29 11:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-20 12:24:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2006-11-05 11:53:38 EST
Spec URL: http://ensc.de/fedora/libextractor/
SRPM URL: http://ensc.de/fedora/libextractor/
Description:
libextractor is a simple library for keyword extraction.  libextractor
does not support all formats but supports a simple plugging mechanism
such that you can quickly add extractors for additional formats, even
without recompiling libextractor.  libextractor typically ships with a
dozen helper-libraries that can be used to obtain keywords from common
file-types.
Comment 1 Mamoru TASAKA 2006-11-21 12:02:46 EST
Well, I don't know this package at all,
however, it seems that 0.5.16 is released.

So would you update this package?
Comment 2 Mamoru TASAKA 2006-12-12 03:53:29 EST
ping?
Comment 3 Enrico Scholz 2006-12-12 14:02:07 EST
* Fri Nov 24 2006 Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.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

Comment 4 Mamoru TASAKA 2006-12-13 23:26:19 EST
Okay, I will check this later.
Comment 5 Mamoru TASAKA 2006-12-14 11:06:12 EST
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.
Comment 6 Enrico Scholz 2006-12-18 03:12:14 EST
* Thu Dec 14 2006 Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.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/
Comment 7 Mamoru TASAKA 2006-12-18 09:55:02 EST
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.
Comment 8 Enrico Scholz 2006-12-21 10:51:31 EST
> * 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).
Comment 9 Mamoru TASAKA 2006-12-22 03:21:52 EST
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?
Comment 10 Enrico Scholz 2006-12-22 07:04:04 EST
* 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
Comment 11 Mamoru TASAKA 2006-12-22 08:16:06 EST
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.
Comment 12 Enrico Scholz 2006-12-27 07:34:08 EST
* Wed Dec 27 2006 Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.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/
Comment 13 Mamoru TASAKA 2006-12-28 12:52:36 EST
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
Comment 14 Mamoru TASAKA 2007-01-09 08:05:51 EST
( I can see this package imported into FE devel/6/5 and
  I think you can close this bug with CLOSED NEXTRELEASE )
Comment 15 Mamoru TASAKA 2007-01-19 08:47:41 EST
( ping? Again I think this bug can be closed... )
Comment 16 Johan Kok 2007-01-20 12:24:09 EST
Closing this bug as NEXTRELEASE
Comment 17 Jeff Sheltren 2009-05-28 17:03:12 EDT
Package Change Request
======================
Package Name: libextractor
New Branches: EL-4 EL-5
Owners: sheltren
Comment 18 Jason Tibbitts 2009-05-29 11:38:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.