On 1/12/06, Dennis Gilmore <dennis@xxxxxxxx> 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
