Mark: > Brian Cameron wrote: >> >> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >> timeout on August 12th. See attached onepager. >> >> Brian > <...excerpted from the attachment...> >> 4.5. Interfaces: >> Exported Interface >> Interface Classification Comments >> ----------------------------- -------------- >> ---------------------- >> SUNWraptor Uncommitted Package name >> SUNWraptor-devel Uncommitted Package name >> /usr/bin/rapper Volatile parser utility >> /usr/bin/raptor-config Volatile config utility >> /usr/lib/libraptor.so.1 Volatile library >> /usr/share/man/man1/rapper.1 Volatile man page >> /usr/share/man/man1/raptor-config.1 >> Volatile man page >> /usr/share/man/man3/libraptor.3 Volatile man page >> /usr/lib/pkgconfig/raptor.pc Volatile pc file >> /usr/include/raptor.h Volatile Header file >> /usr/share/gtk-doc/html/raptor Volatile help file > I notice that most of the exported interfaces are "Volatile". This > seems low, especially since the upstream itself seems committed to > stability (e.g. the notice regarding the ABI/API change on the front > page). Isn't "Uncommitted" more appropriate?
I will leave this question for Jerry to answer. > Also, is this *library* racing another FOSS product -- i.e. will we see > another consuming application show up soon? I ask merely out of > curiosity -- I believe we have a pattern of delivering (FOSS enabling) > libraries in LSARC, whereas PSARC often challenges libraries without > consumers. And this seems like such a specialized library. . . My understanding is that this library will be used in the next release of Tracker that we ship, thus the need to integrate it. > Also, another point of personal clarification -- I notice not all > projects complete a FOSS checklist. This one didn't seem to. I suspect > that's fine, except that in this particular case, I couldn't find a > binding level. I notice that's an explicit question in the FOSS > checklist, but reviewing many recent one-pagers reveals that this detail > is very often omitted. What is the binding level here? This case is intended to be included only in future releases of Nevada, so a minor release binding. > One final nit -- are we really interested in delivering raptor.pc? > It's not really been common practice up until now to deliver those > ./configure artifacts. The pc file is not a configure artifact, it is an input file into pkg-config. If you look in the /usr/lib/pkgconfig directory, you will notice that most free/open source modules provide pc files so that other modules can identify if the dependency is on the system, what version is installed, etc. Brian
