Bug 168310

Spec Name or Url (OLD): swish-e-2.4.2.FC4.spec.1
Spec Name or Url: swish-e-2.4.2.FC4.spec
SRPM Name or Url: swish-e-2.4.2-1_F4.src.rpm
Description: A swish-e package for Fedora Core 4

Spec Name or Url (OLD): swish-e-2.4.2.FC4.spec.1
Spec Name or Url (OLD): swish-e-2.4.2.FC4.spec.2
Spec Name or Url: swish-e-2.4.2.FC4.spec
SRPM Name or Url: swish-e-2.4.2-2_FC4.src.rpm
Description: A swish-e package for Fedora Core 4

Please post an _URL_ to a downloadable src.rpm package.

On fedora-extras-list some months there has been activity with
regard to swish-e, too.

Good question.
I'll reload them to http://users.cwnet.com/bkyoung/swish-e soon.

Also, check fedora extras cvs devel for swish-e package.

Unless fedora-extras-list activity is within the last week, it probably is not
associated with this package.

http://fedoraproject.org/wiki/Extras/NewPackageProcess
Please understand that is improper and offensive to import into CVS without
approval by the Extras new package process.  Please review the process document.

Created attachment 119267 [details]
3_FC4 rpmlint output

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.3
SRPM Name or Url: swish-e-2.4.2-3_FC4.src.rpm

To avoid reopenings,  an automatic approval time limit for review requests
should be implemented.

Attached lintout.

(In reply to comment #7)
> To avoid reopenings,  an automatic approval time limit for review requests
> should be implemented.

Are you suggesting automatic approvals without any sort of review?  Thats one of
the worst ideas I've heard in a long time.  The sheer number of possible
security problems that could occur boogles the mind.

Personally, I think this package should be removed from CVS and the Bugzilla
component list, since it appears to never even had a review, as Warren stated in
comment #5.

>Are you suggesting automatic approvals without any sort of review?  Thats one of
>the worst ideas I've heard in a long time.  The sheer number of possible
>security problems that could occur boogles the mind.
Must not take much to boggle (spelled correctly) your mind. Well reviewed
packages tend to have same or more security problems, many supported by people
receiving thousands of dollars a month to do so. Unlike persons packaging for
Open Source, with the intention of building a positive and supportive
atmosphere. I take it you do not trust any of, or even the, entire Open Source
community?

>Personally, I think this package should be removed from CVS and the Bugzilla
>component list,
Such a mistake to do so. But that is what I would expect from people like you.
If you were to take version 2.4.2 of swish-e(1) on an x86_64 system, it would
fail. Patches in this package, unavailable elsewhere, correct that problem. I
call that improving the quality and security, not introducing additional
problems and security risks. But then I know a little about swish-e. Do you?

>since it appears to never even had a review, as Warren stated in
>comment #5.
That is what the time limit is all about. If a few reviewers do not have the
time to review all the packages, then let them in so users may sort them out,
and benefit from them.

At some point, we may consider splitting packages into "reviewed" and
"unreviewed" -- the idea has some merit.  For now, though, the rules are the
rules.  Please adhere to them.   Thanks.

Created attachment 119300 [details]
4_FC4 rpmlint output

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.4
SRPM Name or Url: swish-e-2.4.2-4_FC4.src.rpm



>At some point, we may consider splitting packages into "reviewed" and
>"unreviewed" -- the idea has some merit.  For now, though, the rules are the
>rules.  Please adhere to them.   Thanks.
Standardization is the foundation of the Open Source community, which presents a
trustworthy and familiar interface for all users. It just takes some of us a
little longer to read and apply all of em.

A little feedback on: swish-e-2.4.2-4_FC4.src.rpm

> %define	name	swish-e
> %define	version	2.4.2
> %define release 4_FC4

This is commonly considered bad style. All three macros are defined
via the "Name: ...", "Version: ..." and "Release: " tags.

> %define release 4_FC4

Fedora Extras packagers have the option to append %{?dist} like in
"Release: 4%{?dist}" instead of making up their own dist tags. "_FC4"
must go, also because "FC4" is older than "fc3" in RPM version comparison.
%{?dist} expands to ".fc4", ".fc3" and so on, in the Fedora Extras build
system and is also understood by "make tag" in Fedora Extras CVS.

> %define httpd_conf_d_dir /etc/httpd/conf.d

/etc is %_sysconfdir, which you use elsewhere, too.

> # Conditionals
> # --with debug: Replaces -O2 with -O0 in CFLAGS
> #		Builds debuginfo package.
> #		Defines compile time macro DEBUG.
> # --without debug OR missing: Disables debuginfo package AND Removes -g.
> 
> %{!?_with_debug:%define debug_package %{nil}}

Why? Default build ought to use $RPM_OPT_FLAGS and create a good
"debuginfo" package automatically. If compiler flags are modified to
not include -g, patch the code. Disabling the debuginfo package is a
last resort only.

> Summary:        SWISH-E - Simple Web Indexing System for Humans - Enhanced

Repeating the package name in the summary is considered bad style.
The summary is the only important thing.

> Name:           %{name}
> Version:        %{version}
> Release:        %{release}

Fill in the values here, not via defining %name, %version and %release.
Avoid multiple places where to define these values.

> Requires:       libxml2 >= 2.6.19, pcre >= 5.0, zlib >= 1.2.2.2

All these three should be automatic already via SONAME requirements,
look at "rpm -qR swish-e" of your binary package. It didn't build for
me (attaching log later), so I couldn't check this. Explicit dependencies
on package names make it much more difficult to move/upgrade libraries.

> BuildArch:      i386 x86_64

Why that? Did you mean to do "ExcludeArch: ppc ppc64" possibly? If so,
the spec file should give a rationale (and later link to a bugzilla
ticket where the failure is tracked).

> %description
> Swish-e is Simple Web Indexing System for Humans - Enhanced

What is it called? Swish-e or SWISH-E?

> %description    perl
> PERL SWISH-E language bindings and scripts.

It's called "Perl", not PERL.

> %package        perl
> Summary:        SWISH-E - PERL Scripts and Modules
> Group:          Applications/Internet
> Requires:       %{name} = %{version}, perl >= 5.8.0

Couldn't build the package, but I believe that since you install into
versioned vendor locations, you want a different dependency on "perl":

Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))

> %package	devel

The -devel subpackage ought to require the full %version-%release of the
main package to always stay in sync with any patches, changelog entries, ...

> %build

Can you please explain what all that stuff in there is supposed to
achieve. Why don't you just use the %configure macro, which takes care
of setting CFLAGS, CXXFLAGS, FFLAGS, as well as setting --prefix and friends?

> for i in $(find . -name config.guess -o -name config.sub) ; do
> 	if [ -f /usr/lib/rpm/redhat/$(basename $i) ]; then
> 	%{__rm} -f $i
> 	%{__cp} -fv /usr/lib/rpm/redhat/$(basename $i) $i
> 	fi
> done

Without any comment at all? :-O

> [ "${RPM_BUILD_ROOT}" != "/" ] && [ -d ${RPM_BUILD_ROOT} ] && rm -rf
> ${RPM_BUILD_ROOT};

This check only decreases readability. Delete it. You define a good
buildroot at the top. This has been beaten to death in older reviews
and on extras-list.

> for i in $RPM_BUILD_ROOT%{_mandir}/man1/*.gz; do
> 	%{__rm} -f $i
> 	done

Why? Things like that ought to be commented.

> %post devel -p /sbin/ldconfig
> 
> %postun devel -p /sbin/ldconfig

Why?

> %files
>
> %{_libdir}/swish-e/swishspider

Directory %_libdir/swish-e is not included, can be created with bad
permissions and would not be removed upon erasing the package.

> %files

GNU GPL must be included in the main package at least. The lawyers want that.

> %files perl
> %defattr(-, root, root)
> %{_libdir}/swish-e/perl/SWISH/Filters/Doc2txt.pm

Lots of directories not included in that path. Also, are you aware of
using wildcards in the %files section? Is it really necessary to list
each and every file manually?

> %{_datadir}/swish-e/search.tt

%_datadir/swish-e not included in the package either.

> %{_libdir}/libswish-e.la
> %{_libdir}/libswish-e.a

Avoid packaging libtool archives and static libraries unless there is
good reason to package them. Libtool archives create nasty inter-library
dependencies which also bloat up build requirements.

Created attachment 119355 [details]
compressed build failure log

Build failure on Fedora Core 5 Development.

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.5
SRPM Name or Url: swish-e-2.4.2-5_FC4.src.rpm

Thanks for the above comments, will review them shortly and incorporate into 6_FC4.

Cannot seem to get the perl make test to work. Suggestions appreciated.

Created attachment 119508 [details]
5_FC4 rpmlint output

Created attachment 119509 [details]
5_FC4 build output

> Cannot seem to get the perl make test to work. Suggestions appreciated.

This is because you have been ignoring the warning in the build log
that no library is found for -lswish-e, and as a result the Perl
API.so module is not linked against it and contains undefined symbols.

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.6
SRPM Name or Url: swish-e-2.4.2-6fc4.src.rpm

>> # Conditionals
>> # --with debug: Replaces -O2 with -O0 in CFLAGS
>> #		Builds debuginfo package.
>> #		Defines compile time macro DEBUG.
>> # --without debug OR missing: Disables debuginfo package AND Removes 
-g.
>> 
>> %{!?_with_debug:%define debug_package %{nil}}

>> %build

>Can you please explain what all that stuff in there is supposed to
>achieve?

>Why? Default build ought to use $RPM_OPT_FLAGS and create a good
>"debuginfo" package automatically. If compiler flags are modified to
>not include -g, patch the code. Disabling the debuginfo package is a
>last resort only.

This is all part of the
rpmbuild -ba --with debug swish-e.spec
stuff. The 'standard' debuginfo package tends to have periodic -g/-O2/gdb/gcc
problems, and this has worked well for me. And,  as I use this for development
purposes, is a easy way to create a pure -g/-O0 debuginfo package.

Removing -g from the standard build reduces build time on large packages, but
not relevant here.

To get a nice -O2 debuginfo package, the
%{!?_with_debug:%define debug_package %{nil}}
may be commented out.

>> BuildArch:      i386 x86_64

>Why that?
Can only verify proper (whatever that means) build on i386 and x86_64
architectures at this time. Deleted.

--------

>This is because you have been ignoring the warning in the build log
>that no library is found for -lswish-e, and as a result the Perl
>API.so module is not linked against it and contains undefined symbols.

ldd API.so is not showing a dependency on libswish-e.so.

Created attachment 119510 [details]
6fc4 build output

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.7
SRPM Name or Url: swish-e-2.4.2-7.fc4.src.rpm

Using LIBS instead of CFLAGS to set prebuilt libswish-e.so location for perl
make test.

Created attachment 119512 [details]
7.fc4 build output

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.8
SRPM Name or Url: swish-e-2.4.2-8.fc4.src.rpm

Created attachment 119514 [details]
8.fc4 rpmlint output

Created attachment 119515 [details]
8.fc4 build output

> The 'standard' debuginfo package tends to have periodic
> -g/-O2/gdb/gcc problems,

Has this been bugzilla'ed?

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.9
SRPM Name or Url: swish-e-2.4.2-9.fc4.src.rpm

>Has this been bugzilla'ed?
Not for swish-e, but, most recently, the xorg-x11 package.

Created attachment 119557 [details]
9.fc4 build output

Created attachment 119558 [details]
9.fc4 rpmlint output

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.10
SRPM Name or Url: swish-e-2.4.2-10.fc4.src.rpm

Created attachment 119566 [details]
10.fc4 build output

Created attachment 119567 [details]
10.fc4 rpmlint output

See README for files descriptions within swish-e directory.
Spec Name or Url: swish-e.spec.11
SRPM Name or Url: swish-e-2.4.2-11.fc4.src.rpm

Created attachment 119718 [details]
build 11.fc4 output

Created attachment 119719 [details]
11.fc4 rpmlint output

Spec Name or Url: swish-e.spec.12
SRPM Name or Url: swish-e-2.4.2-12.fc4.src.rpm

There are numerous script-without-shellbang errors. Not sure why.

The swish-e-perl only-non-binary-in-usr-lib error is a consequence of the
swish-e(1) -S indexing method and the hard-coded /usr/lib prefix in the
documentation. The program is expected to be in libexecdir and attempting to
relocate to %{_datadir} breaks existing functionality. Configure using
libexecdir as %{_datadir}/swish-e would work, but would move both helper scripts
and Perl modules to /usr/share/swish-e.

Hopefully 12.fc4 conforms with your suggestions and Extras
standards/requirements as best it can.

Created attachment 119744 [details]
12.fc4 build output

Created attachment 119745 [details]
12.fc4 rpmlint output

Removed swish-e from CVS because it was imported in violation of process.

Yes. Removing the prematurely imported files from the original RPM package is a
good idea. However, removing the swish-e package completely is a bad idea, and
should be reconsidered. I would encourage adding the 12.fc4 files, and a FC4
branch created.

Most major distributions have a swish-e port/package. FreeBSD 5.3 uses a swish-e
2.4.2 port without any patches, does not build the API.so perl/C interface, and
does not alias the documentation into the local webspace. The port file listing
is attached as freebsd-swish-e-2.4.2.txt. FreeBSD is now using swish-e-2.4.3,
and I hope to update the fc4 rpm to 2.4.3 after successful 2.4.2 package creation.

The 12.fc4 rpm is an enhanced version of the original swish-e package and builds
the C/perl interface. Forcing Fedora users to install from a generic package
instead of a quality RPM is a disservice and violates the very nature of the
Fedora Extras purpose.

Created attachment 120297 [details]
FreeBSD swish-e-2.4.2 pkg_info -L listing

There is a clearly defined method for getting a package into Fedora Extras. 
Once it has been approved by a reviewer, that is the time for the package to be
imported into CVS.  Importing it into CVS before it meets the packing quality
standard for Fedora Extras, also does our users no good.

Please refer to:
http://fedoraproject.org/wiki/Extras/NewPackageProcess
http://fedoraproject.org/wiki/PackagingGuidelines

This has already been discussed. Everybody agrees the first few RPMs failed the
Fedora Extra standards. I was generally following the Fedora Distribution RPMs,
like the kernel which uses _FC4 naming convention, and the rpm package that has
executables in /usr/lib, and did not realize that Fedora Extras had different
standards. I also was just modifying a supplied (in the Swish-e distribution)
generic RPM spec file that failed all Fedora Extra standards, but worked just
fine for casual use.

The 12.fc4, and the new 13.fc4 RPM should meet Fedora Extra requirements. If, in
meeting those requirements, some functionality is broken, a note in the RPM
encourages users to post constructive comments to resolve the issues, and
overcome parts of the Swish-e build system that predates Fedora Extras.

I'm assuming that Swish-e itself passes Fedora Extra standards, as it is present
in just about all distributions.

Point by point comparison:
http://fedoraproject.org/wiki/PackagingGuidelines
1.1 http://fedoraproject.org/wiki/PackageNamingGuidelines
  1.1 Matches upstream tarball.
      No '_' in name.
  1.2 No multiple versions at this time.
  1.3 swish-e.spec is proper.
  1.4 Package version 2.4.2
  1.5 Proper use of %{dist}
  1.6+ Proper use of addon perl package names.
1.2 Passes Legal
1.3/1.4 Modified an existing package, then rewrote it, matches with minimal
fedora-newrpmspec
1.5 rpmlint errors are reduced to a few in debug rpm and a few in Perl modules.
The errors are consistent with errors in other approved packages.
1.6 ChangeLog meets requirements.
1.7 No packager/vendor/ copyright tag used. Summaries do not end in period.
1.8 Buildroot tag acceptable.
1.9 Requires are assumed to be automatic.
1.10 fedora-rmdevelrpms passed.
1.11 Summary and descriptions appear okay.
1.12 Encoding passed.
1.13 All docs in separate sub package (named correctly). Uses Documentation group.
1.14 Static libraries excluded.
1.15 No duplication of system libraries.
1.16 Configuration files are marked.
1.17 No desktop files.
1.18 Macros are used liberally.
     Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS
consistently.
1.19 Timestamps okay.
1.20 Parallel make not used.
1.21 Scriptlets meet requirements.
1.22 Running scripts at proper times.
1.23 Conditional dependencies are excluded for default build.
1.24 Package built in user account.
1.25 Not relocatable.
1.26 Code vs Content seems acceptable.
 

http://fedoraproject.org/wiki/PackageReviewGuidelines
1 Review Purpose

"This does not mean that the package (or the software being packaged) is
perfect, but it should meet baseline minimum requirements for quality."

Package meets minimum quality requirements.

1.2 Review Process
1.2.1 Contributor
 Still on step 3.
1.2.2 Reviewer
Possible blocker:
      - MUST: If a package includes something as %doc, it must not affect the
runtime of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.

Some examples are dependent on files in the docs, but they are in a separate doc
package. Installing the docs package using --exludedocs makes no sense.

Other than a few blockers caused by a outdated build system (swish-e), the RPM
should be acceptable for Fedora Core 4. A new RPM package will be required for
fc5 and 2.4.3, most likely due to libxml2 changes.

Created attachment 120325 [details]
13.fc4 build output

Created attachment 120326 [details]
13.fc4 rpmlint output

Everyone in here slow down a bit, please. A lot of packaging issues
with this package have been fixed. One major thing that makes this
ticket very unusual is the amount of traffic/content caused by
superfluous comments and attachments. This is scary and makes it
very difficult to concentrate on the important bits.

The 14.fc4 Swish-e RPM package advances the Fedora Extras Swish-e RPM from
"meets minimal requirements" to "development ready".

All custom RPM Perl dependency packages on the build/development i386 fc4 system
have been replaced by Fedora Extra packages. Any dependencies missing from
Fedora Extras have been posted to the source site (and will be added to Fedora
Extras upon favorable review). Basic functionality of the RPM (search.cgi,
swish.cgi, spider.pl, etc) has been verified on the Fedora Core 4 (with no
updates) build system. Basic functionality in this case means the operations
outlined in the documentation appears to complete properly without any missing
library or execution errors. Note, that to accomplish this, some scripts
required modification, especially with regards to index file locations. However,
this RPM has not been tested on a production server.

Also, the RPM should now build on all architectures, not just i386.

The perl-SWISH sub-package should build "noarch", but adding
BuildArch: noarch
to the sub-package declaration results in failed debug build. Suggestions
appreciated.


>superfluous comments and attachments. This is scary and makes it
>very difficult to concentrate on the important bits.
I'll avoid posting rpmlint output and fc4 build output for future package versions.

Created attachment 120509 [details]
14.fc4 build output

Created attachment 120510 [details]
14.fc4 rpmlint output

Spec Name or Url: swish-e.spec.15
SRPM Name or Url: swish-e-2.4.2-15.fc4.src.rpm

Added perl-SWISH-Stemmer sub package.
Finally! Finally eradicated all blankety blank beep beep #$$**&^ rpmlint errors
and warnings.
I guess rpm still requires %{_arch} to remain constant during build; Therefore,
the perl-SWISH subpackage must remain i386 instead of noarch.

This package is proof positive that reasonable standards improve quality and
promote a trusted environment.

Spec Name or Url: swish-e.spec.16
SRPM Name or Url: swish-e-2.4.2-16.fc4.src.rpm

Moved the examples from the swish-e-doc sub-package to the swish-e-perl
sub-package. The swish-e-doc sub-package now has no perl dependencies. The
swish-e-perl sub-package now contains all helper scripts and examples. Also,
adjusted some Group settings and shortened the name of some documentation files.

user.cwnet.com/~bkyoung/swish-e
Spec Name or Url: swish-e.spec.17
SRPM Name or Url: swish-e-2.4.2-17.fc5.src.rpm

Fixed an RPATH issue, and advanced to FC5-test1. No new major problems have been
reported recently, so if there are no objections, I'll add it to extras.

This package still hasn't been approved yet.  This package still appears to be
at step 6 of the procedures for inclusion to FE.
http://fedoraproject.org/wiki/Extras/Contributors

The person that reviewed it never promoted it to FE-REVIEW, so FE-ACCEPT is blocked.
http://fedoraproject.org/wiki/PackageReviewGuidelines

Are you referring to comment 13?  Based on his comments, I don't believe that
Michael ever approved this.  It looks like he was only providing some feedback
on your package.

The mentioned issues, and others, are resolved and acceptable. Only the primary
reviewer can accept the package.

There seems to be a communication break-down here.  Where is the review that
states that this package has been approved?  Looking through the comments here,
I cannot see any that state this.  In addition, I can only assume that you think
Michael provided a review, but it looks like he was only providing you some
feedback, since he never assigned the bug to himself for review.

Looking at you account information, it appears Elliot Lee is your sponsor.  I
would suggest working with your sponser on getting this package approved, since
the information on the wiki obviously isn't providing you with enough
information on the steps necessary to get this into FE.

It is the sponsor's responsibility to make sure a contributor is educated in the
guidelines and process.

Spec Name or Url: swish-e.spec.18
SRPM Name or Url: swish-e-2.4.2-18.fc4.src.rpm

Sigh. Unfortunately, the blame for this fiasco rests squarely on my shoulders.
Elliot cannot, and should not be required to, read the rules/procedures to every
contributor.

Fixed reported:
/usr/bin/perl: symbol lookup error:
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/SWISH/API/API.so:
undefined symbol: SwishErrorsToStderr

Fixed reported:
API.so invalid standard RPATH error when rebuilt on system with installed
/usr/lib/libswish-e.so

Spec Name or Url: swish-e.spec.19
SRPM Name or Url: swish-e-2.4.2-19.fc5.src.rpm

While fixing 19.fc5, a lib path was incorrectly adjusted. This returns it to the
correct value.

#60 was more complicated. After the changes, the paths had to be adjusted, yes,
but PERL5LIB and LD_LIBRARY_PATH had to be re-added. This does not affect
runtime. The 20.fc5 package fails check-rpaths if the spec sed LD_RUN_PATH line
is commented out with/without Swish-e installed.

Added a swish-e-default sub-package, which helps for testing purposes (needed!).
Perhaps a bit much for Extras?

Thanks to the fedora-devtool guys for tools to catch these problems.

Because of all these minute changes, I've verified the package yet once again:

PackagingGuidelines
* Normal package naming ok.
*   Upstream name contains dash '-', but ok.
*   Addon Perl sub-packages match CPAN, but some use all capitols.
*   Doc subpackage -doc ok.
*   spec file name ok.
*   Version matches upstream.
*   %{?dist} used correctly in Release.
* Legal: Includes OSI/GPL.
* No Packager, Vendor, or Copyright tags.
* Good buildroot tag.
* Requires look good. Patch requires specific libxml2. 
* BuildRequires looks good.
* Summaries/Descriptions ok. American English and Spelling.
* Spec file  ASCII.
* -doc sub-package. Group: Documentation.
* Includes libraries.
*   No .la or static libs.
*   Devel subpackage used.
* %config(noreplace) used.
* Macros use ok.
* RPM_BUILD_ROOT/RPM_OPT_FLAGS variable style.
* Uses %{__make} %{?_smp_mflags} instead of make %{?_smp_mflags}
* Conditional dependencies not required.
* Not relocatable.
* Content ok (documentation).

ReviewGuidelines
* MUST Items
*   Rpmlint ok.
*   Name ok.
*   Spec ok.
*   Packageguidelines ok.
*   License OSI/GPL.
*   License in doc of primary package.
*   License field matches included license.
*   Spec file in American English.
*   Spec file not a Obfuscated  Code Contest candidate.
*   UNABLE TO VERIFY MD5SUM UPSTREAM.
*   Build on FC4/FC5-test1 i386
*   No dups.
*   Good perms.
*   %clean ok.
*   Macros ok.
*   Content ok and code ok.
*   Large doc => -doc package.
*   No runtime files in -doc.
*   Headers in -devel subpackage.
*   No pkgconfig used.
*   Devel contains .so.
*   All subpackages require versioned base as dependency.
*   No .la or static libs.
*   No gui apps.
* SHOULD Items.
*   Package tests properly on i386.

OTHER
* Proper use of ldconfig
* Package owns all files/directories it should
* Owns all directories it uses
* Builds with package already installed.
* Build test ok with package already installed.
* Builds without package installed.
* Build test okay without package installed.

Definition of testing the package:
After build, then package install:
cd BUILD/swish-e-2.4.2/perl
perl t/test.t
echo $? == 0

Configuring swish-e-default according to README.default
lynx url/cgi-bin/swish.cgi
runs and entering a search term "swish" returns a results list.

Spec Name or Url: swish-e.spec.23
SRPM Name or Url: swish-e-2.4.2-23.fc5.src.
FIXED: Patches are now relative, and not absolute.

The Swish-e RPM package, in its current state, adds "simple" search capabilities
to Fedora (Thanks to patient reviewers and testers for finding many errors that
required correction.)

The reason for inclusion into Fedora, however, is the swish-e-default
subpackage. Thanks to a set of reasonable standards (which we all benefit from),
packages install documentation into a predictable location. The swish-e-default
subpackage processes these directories, and, thru the Swish-e httpd cgi
interface, provides users a means to search for terms.

What is not clear from the guidelines is if additional functionality should be
provided as a subpackage, or a completely separate package?

The intention of my comments was to offer help, to report several
problems and bugs in the initial packaging, and to point out that the
imported package didn't even build.  Once it would build at least,
my hope was that those who had worked on packaging swish-e before,
would join and add final comments.

The reason I never advanced to actual reviewing the package alone
is the high number of comments and revisions done by the packager
and the continuing number of unsual issues. The procedure in this
ticket is very different from saying "here is a package ready for
review". This thing is a constantly moving target. See comment 46.
62 comments, and only 6 are mine. Searching for actual answers to
questions in all this flood is tiresome. The additional periodic
pressure on volunteer resources (comment 52, comment 7) is simply
not nice either.

Communication is important to the success of any endeavor. The outcome of this
one would indicate a communication deficiency from the start. I should have
clearly stated my intentions.

What is important is that the intentions of all involved was to get the package
to meet all requirements. In my opinion, the package does (or at least the ones
I know about), plus adds benefit to the entire Fedora Community by providing
documentation search services for those who wish to install the swish-e-default
sub package.

At this point, the package is about the best I can do. If packagers/ reviewers
approve the package and approve searching the documentation in this manner, and
would like to adjust their HTML documentation to be included, then they are free
to do so.

Cheers,
-Byron

Bryon,

Jumping in fresh here, I just have been appointed sponsorship rights and as such
I'm looking through bugs in FE-NEEDSPONSOR. 

You are clearly willing to invest time in FE and seem to be doing your best,
however sofar things haven't been going really smoothly. Mainly I believe
because you've been doing your best too much.

I would like to suggest a way out of the current stale-mate, as it would be a
pitty to loose a potentially active volunteer for Fedora. Clearly the problem
isn't lack of involvement or not investing enough time, so I believe we should
be able to work this out.

Here is what I suggest:
-update your swish-e package to build and work properly under Fedora Core 5, 
 keeping all the packaging and reviewing guidelines into account.
-start a new review ticket for swish-e, or if swish-e has dependencies not yet 
 in FE-5 for one of those depencies. This current ticket is to cluttered to be
 of any use, put me in the CC for this ticket or mention it here.
-in this new review do _NOT_ keep posting new versions, if there is a new 
 upstream version, or you have some packaging improvements hold these back,
 you're free to incorperate those once your innitial submission is approved. But
 reviewing a target moving as fast as you've been moving in this ticket is 
 nearly impossible.
-wait (a week or so) for a full review to be done, a full review can be 
 recognised by the reviewer assigning the bug to him, changing the blocker bug 
 to FE-REVIEW and by a long list of MUST items being checked of one by one.
-this full review will probably contain a few must-fix and should-fix items,
 fix these (and only these, otherwise we have to start over again!) and post
 a new version.
-usually after one iteration, but sometimes more of must-fix -> new release your
 package will get approved and you are free to import and build it.
-After the initial version is approved, you're free to make improvements, but 
 you should still stick to all the guidelines, you no longer need a review for
 each new release.

I hope this can get things moving forward and welcome to the FE community!

Appreciate your comments, suggestions, and thoughts on this packages direction.

The ultimate goal of this Swish-e packaging effort has been meet, in a much more
reliable and capable manner, by Beagle and other packages. I doubt anyone will
be using this as a template/ example for adding functionality to Fedora in the
future.

Your suggestion of closing this request seems to be the best course of action.

Opening a new request for a Swish-e only package meeting all the Fedora
guidelines/ standards and similar to other distribution packages is certainly
possible. Depending on the level of SELinux support desired, others competent in
SELinux policy may or may not be required to add policy to the new Swish-e
package and/or the selinux-* packages.

My interest in Swish-e and my Swish-e based applications are focused on Swish-e
2.42. In the future, I hope to base my applications on other search
technologies, but would like to see a Swish-e package (mine or other) in Fedora
to support the Swish-e based versions of my (and others) applications.

(In reply to comment #66)
> The ultimate goal of this Swish-e packaging effort has been meet, in a much more
> reliable and capable manner, by Beagle and other packages. I doubt anyone will
> be using this as a template/ example for adding functionality to Fedora in the
> future.
> 

The fact that a package with similar functionality has been added does not mean
that swish-e shouldnot be added. Free software / Fedora Extras is all about
choice, nowhere in the FE guidelines it says that it is discouraged or forbidden
to package Free Software with somewhat redundant functionality. So I encourage
you to still go ahead and start a fresh new review for swish-e if you still want
to and use it yourself.

> Your suggestion of closing this request seems to be the best course of action.

If my above comment hasn't helped to make you restart the review process for
swish-e please close this bug as won'tfix.

Closing as wontfix