Eiciel (was: Re: Package review stats)

[Michael Schwendt]

On Sat, 08 Jul 2006 14:24:57 +0100, Andy Burns wrote:

> Jason L Tibbitts III wrote:
> 
> > Some sat for so long that it would not be surprising
> > to me if the the submitters had completely lost interest.
> 
> I admit I *partly* lost interest in getting my first package 
> reviewed/sponsored, I don't know if I haven't followed right procedures, 
> or haven't spoken up loudly enough to attract attention
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758

There has been quite some traffic in that ticket. Feedback on mistakes in
the packaging, for instance. 17 comments in total is much more than many
trivial-to-review packages get. One cannot say that you have been ignored. :)

Let me point out some things here instead of posting this in bugzilla:

The ticket is assigned to you instead of the default dummy owner of
Package Review tickets. This may be misunderstood by anyone who browses
the FE-NEW list, looking for "unassigned" package reviews.

When loading the ticket, it appears as if Paul Howarth is doing reviews
already.

Some of the package revisions look half-hearted, though. As somebody who
has contributed reviews since the era before the Fedora Project, let me
tell you that it can also happen that reviewers lose interest if the
review'n'approval process gets too long and tiresome for a package. This
can lead to potential sponsors waiting longer and observing you and your
packages for a longer time. Usually it should be come obvious that the
package submitter spends more time and thought into the package than the
reviewer. Because it is the packager who wants to maintain the package
later on. From my point of view, as much as I like to sponsor new
contributors as soon as they provide one or two clean packages (fixing any
reported issues without too much trouble), I would consider it a mistake
to sponsor somebody, who will likely run into too many problems when
working inside Fedora Extras CVS, with the buildsys, with the need to
respond to bug reports, and so on. In addition to perusing existing
documents, new [unsupported] contributors can seek for communication on
fedora-extras-list actively, ask questions, request help and hints and
demonstrate general interest in becoming a packager. On the contrary, new
contributors who modify their offered packages only reluctantly or
half-heartedly, give the [possibly false] impression that they don't
really want to adhere to packaging guidelines and project policies.

If a reviewer supplies a patch against your .spec, accept it or refuse it
and discuss the reason. As a rule of thumb: don't modify your package too
much in response to reviewer's feedback. Better ask before applying major
changes, especially if you are not sure about them. This makes reviewing
much easier.


Taking a brief look at your latest package:

$ rpmlint eiciel-0.9.2-4.src.rpm 
E: eiciel hardcoded-library-path in /usr/lib/debug/%{_bindir}/%{name}.debug
E: eiciel hardcoded-library-path in /usr/lib/debug/%{_libdir}/nautilus/extensions-1.0/lib%{name}*.debug

This smells like "packager confusion". Right now I can't take the time to
read all 17 comments in the review ticket (writing all this probably has
taken more, but well, ...). There is cleanup in the spec file needed. The
debug files need not be excluded at all. They are not included in your
package unless you include them explicitly or recursively (e.g. by
including %_libdir which in turn would be a packaging mistake).


> BuildRequires: nautilus

Although this works, you really want "nautilus-devel", the virtual
package for the Nautilus extension development files.

"Nautilus" is written with upper-case 'N', so I would do the same
in the package %description.


> %{_datadir}/%{name}/*

With this, the directory %{_datadir}/%{name} would not be included in
your package. Listing the binary rpm confirms it:

drwxr-xr-x  /usr/share/eiciel/doc
drwxr-xr-x  /usr/share/eiciel/doc/C
-rw-r--r--  /usr/share/eiciel/doc/C/eiciel.xml

The fix is this %files entry:

%{_datadir}/%{name}/

This includes the directory and the entire tree in it. The explicit slash
at the end makes the .spec file easier to read. You see immediately that
this entry includes a directory [recursively], instead of a single file.
The package listing will look like (notice the top dir!):

drwxr-xr-x  /usr/share/eiciel
drwxr-xr-x  /usr/share/eiciel/doc
drwxr-xr-x  /usr/share/eiciel/doc/C
-rw-r--r--  /usr/share/eiciel/doc/C/eiciel.xml


> Summary:        Eiciel graphical access control list editor

Better:
Summary: Graphical access control list (ACL) editor

In wide parts of the RPM packaging world and for the majority of packages,
it is considered bad taste to repeat or mention an application's name in
the Summary. There is the package name "eiciel", which is very likely
displayed together with the summary. And for anyone who doesn't know that
"Eiciel" is a name, above summary is confusing. The one important thing to
mention is the summary is to give a brief description of what this package
does: it provides a graphical access control list editor. Everything
beyond that can go into the %description.


> -rw-r--r--  /usr/share/applications/eiciel.desktop
> -rw-r--r--  /usr/share/applications/fedora-eiciel.desktop

Two desktop entries. The one that appeared here in the menu does not work:

  Could not launch menu item

  Details: Failed to execute child process
  "/home/roger/eiciel/TEST/bin/eiciel" (No such file or directory)

This indicates that you either want to remove "eiciel.desktop" or use it
as the source for "desktop-file-install", adding vendor and your own
changes, and using --delete-original to get rid of it.