beagle

[Jeff Spaleta]

On 1/12/06, Dennis Gilmore <dennis at ausil.us> wrote:
> To make beagle as useful as possible it needs to be linked against some
> packages in extras.  1 is gnumetric to index spreadsheets 2 is wv  to index
> word documents
>
> http://www.beagle-project.org/Optional_prerequisites
>
> ok looks like gnumetric  is run time only  so it should work as
> --enable-ssindex  is enabled in gnumetric however  end users may complain
> that indexing is not happening  if they dont install gnumetric themselves.
>
> so wv  would need to be added to core and to give users best experience
> gnumetric  would need adding back so beagle  could require it.

The question is... is it appropriate to pull back the entire gnumeric
code base.. to make an optional runtime feature a hard requirement?
Should we be relying on a group definitions instead to pull the
optional runtime features in instead of making them hard requirements
in the packages?  I will point out that the feature looses its
"optional" status by making it a hard package requirement. How is this
different than any optional plugin for other applications?

The existing hard requirement on xpdf because it provides pdfinfo is
also a runtime optional requirement which pulls in a non-default gui
application. But luckily, this requirement is being replaced by
popplers-utils soonish.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177446

The fact that poppler-utils only pulls in cmdline utlities helps
mitigate the complexity of the issue, but I'm still not convinced that
turning a runtime optional utility like pdfinfo into a hard
requirement is a good idea as general policy with regard to how
optional runtime options are treated in packaging. In my perfect
world, runtime optional dependancies would be treated as runtime
optional dependancies and not hard requirements.

In my slightly better world of tomorrow, there would be the ability to
split out the cmdline utility ssindex and ssconvert from the gnumeric
application into a -utils subpackage so beagle could require the
simple cmdline utility without pulling in the gnumeric application, a
non-default gui application to sit in the menu structure next to
openoffice.

This is a real release engineering problem concern what the default
desktop is going to look like. Is beagle being considered for default
desktop functionality? Since nautilus's new search features require
beagle i think  its pretty safe to say that beagle is going to be
integrated into the default desktop.  nautilus requires libbeagle now,
but beagle itself isn't explicitly required...yet.

If  beagle is destined for default destop installs, is the Core
desktop group willing to pull in gnumeric into the default desktop
next to openoffice in the menus solely to satify beagle's runtime
optional dependancy for the cmdline utility ssindex? Or are they
willing to ship beagle in a suboptimal default state. Quite honestly I
don't see much point in beagle at all if its not able to index media.
The magic, whether it be good or ill, is in the index funcationality

If Core and Extras shared the same buildsystem, it would be much
easier to implement ssindex as a gnumeric subpackage similar to what
is happening poppler-utils. Alas, the policy that subpackages can not
straddle the Core/Extras boundary makes implementation of ssindex as
seperate Core item, leaving gnumeric in Extras difficult if not
impossible.

I really don't like seeing applications that were delibrately moved
out of Core into Extras being required in Core again because of rather
2ndy requirement mechanisms.  If gnumeric goes back in for fc5, what
is to say that beagle wont be re-engineered by fc6 to not require
gnumeric. Is the Core release team content to watch application level
items swing into and out of Core on every release? I'm not.

The fact that gnumeric has to be considered to be pulled back in for
beagle... suggests strongly to me that the effort to keep Core and
Extras as strictly seperate entities is simply a waste of effort.  If
there are benefits to community control in Extras, we continually
erode them, by pulling items back into Core and out of the hands of
community members.  I hope the release team takes a look at how much
this gnumeric situation..sucks... and thinks very deeply about how the
selfhosting requirement of Core devoid of Core community package
maintainership ability is undermining the larger goals of long term
community involvement.
I fear we will continue to see more and more problems like this
develop because of the strict seperation of Core/Extras

-jef"doom doom doom"spaleta