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