savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-help-public] Re: [gnu.org #231727] Is libextractor a GNU packa


From: Karl Berry via RT
Subject: [Savannah-help-public] Re: [gnu.org #231727] Is libextractor a GNU package ?
Date: Fri, 08 Apr 2005 12:23:17 -0400

    The following project was submitted to Savannah. It claims to be a GNU
    package but I could not figure out if it was true. Could you give me
    a confirmation, please ?

    Project Full Name:  libextractor
    Project System Name:  libextractor

My notes say that libextractor was accepted by rms to be a GNU package
on March 17, but I do not see the dubbing message.  rms, maybe you
should send that out now?  The maintainer is Christian Grothoff
<address@hidden>.  I'll append the evaluation report.


GNU Evaluation Report
=============================================================================
* General info
** Program name and version:
libextractor 0.4.0 (currently)

** Author (Name <Email>):
Christian Grothoff <address@hidden> [ and a dozen other
contributors]

** Requested by:
rms

** Message-ID:
<address@hidden>

** Should the authors(s) be contacted? (Y/N)
y

** Was this package offered by the author to become a GNU program? (Y/N)
y

** Does the author agree to follow GNU policies? (Y/N)
   If the program is accepted to be part of the GNU system, it means
   that the author become a GNU maintainer, which in turn means that
   he/she will need to follow GNU policies in regards to that GNU program.
y

** Package home page (if any):
http://ovmj.org/libextractor/

** URL to sources (if any):

** Description from author:
library (and command line tool) to extract meta-data from files (such as ID3 
tags, ogg-vorbis comments, image dimensions, author information (from, say, 
PDF or OpenOffice formats), and many, many more.


** Evaluator:
Karl Berry <address@hidden>

** Describe in your own words what job(s) this program does:
A program (and library) for extracting meta-information from many file
formats.

In general it seems fine, but the authors should probably be queried
about:
- Java support
- "GNU/Linux" in various doc files
- better doc, in due time
Let me know if I should do this, and/or if you see anything else.

=============================================================================
* Source Code
** What language(s) is/are the program(s) written in?
C, Java
(As far as I can tell the Java support should be ok on free Java
platforms, but we should check this with the authors.)

** Format: does it have consistent formatting? 
y

** Internal comments:
    Skim a few header files and a few source files.  Can you
    understand each part, at least in the large, from the comments there?
ok

** Portability: does it support GNU/Linux? 
y

* GNU Coding Standards

** Configuration
    (It might or might not use Autoconf/Automake, but it should meet
    GNU Standards.)  In particular, every GNU distribution should come
    with a shell script named 'configure', which should support certain
    standard options, such as --prefix.
ok (automake)

** Compilation
    (It might or might not use Autoconf/Automake, but it should meet
    GNU Standards.)  In particular, the Makefile's should include certain
    standard targets, such as all, install, uninstall, and many others.
ok (automake)

** Internationalization:  does it use gettext? 
y

** User interface:
   Command line: do all the executables support the two standard options,
   `--version' and `--help'?

   GUI: does it work with the X Window System and GTK and/or GNOME?
n/a

   For a C++ library, can it be used from C? 
n/a

   In general, is the UI, at whatever level, clear and usable?
ok

** Performance:     (ok/problematic + notes)
ok

=============================================================================
* Documentation
** Does the package include a good introduction or tutorial?
n

** Does the package include a good reference manual?
    (The introduction or tutorial can be the reference manual as well,
    as long as it does both jobs well.  We think it is good to do both
    jobs with one manual.)
some reference material

** Is the main documentation written in Texinfo?  
    (Ideally it would be, or at least be convertable into Texinfo.)
n (man pages)

** ChangeLog, NEWS:
    GNU packages should have these two files: the first records all
    program and documentation changes, and the second user-visible changes.
y

** Terminology: Does it use "GNU/Linux" (rather than "Linux") for
   referring to the whole GNU/Linux system, and does it use "free
   software" rather than "open source"?
"Linux" needs to become "GNU/Linux" in the ./PLATFORMS file and perhaps
some README's.


=============================================================================
* Licensing
** Source code: specify type.  If GPL v2, explicitly state if the
   license is ``GPL v2 or later''. 
GPL v2 or later

** Dependencies: list the license of each dependency.  This is critical.

** Are there any licensing issues that need to be resolved?
ok

** Does the program recommend or encourage the use of any non-free software?
n

** Does it have certain capabilities that can only be used in
   conjunction with some non-free software package?
n

=============================================================================
* Does the program fit coherently within the GNU system?
y

** Is there a large overlap with some other GNU or free software package?
    (An overlap is when two programs have substantial functionality in
    common, but neither one entirely subsumes the other.  Such overlap
    is undesirable.)  Please check at least the Free Software Directory
    and savannah for similar programs.
n

** Does the program have any gratuitous incompatibilities with other
   GNU packages?
    (For example, a program for searching files in a new way should
    support all the options of grep, except for those that don't make
    sense in this program, so as to attain maximum compatibility between
    the two programs.  For such a program, any grep option which would
    make sense but is not supported is a gratuitous incompatibility.)
n

=============================================================================
* Notes and comments during evaluation
  (Email exchange with author(s), evaluator(s), RMS, etc.)

Additional info from author.

> * Code
> ** Dependencies:
>     Please list the package's dependencies (source language, libraries,
> etc.).

libz, libltdl (libtool), optionally libvorbisfile, libgsf+glib (gnome)

> ** Configuration & compilation:
autotools are used.

> ** Documentation:
Currently, we have two man-pages and HTML documentation on-line, as well as 
source-code documented in the style of doxygen.

> * Licensing:
GPL.

> * Similar projects:

libextractor is in the Free Software Directory.  Various similar projects are 
listed on our webpage, the closest is a PHP library (getid3). We started the 
project about 3 years ago because we could not find a tool to do the job (the 
closest was 'file', followed by 'grep').  

> * Any other information, comments, or questions:

Not really :-)


=============================================================================
* Status: (open | working | closed)
closed

** Activity Log:
2005-01-17 (karl) received gnueval-input form.
2005-03-14 (karl) did eval, sent to rms.
2005-03-15 (karl) rms concurs; asked author about points above; author
                  says ok; wrote rms back.
2005-03-17 (karl) accepted.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]