Hi Guys,
We need more the two responses to pull together a coherent packing
strategy going forward. In particular I want feedback from potential
platform maintainers that are up for helping build binaries for each
platform. My ideal is for use to use the same granularity and naming
of packing for all platforms.
One constraint already placed out there is fitting in with existing
packaging conventions. For instance if I check Kubuntu 8.10 I get
libopenscenegraph7 (OSG-2.4) and libopenscenegraph-dev,
openscenegaph,
libosgal and libosgcal packages.
Without installing these I can't see exactly what parts of the OSG
come along with it.
I believe a good package layout would be in step with the major
dependencies that that bring with it. For instance the core OSG
package could just depend upon C++, OpenGL, GLU, X11/Win32/Carbon.
Without freetype and the image plugins it isn't that useful though
unless you have a very tightly focused vis-sim app.
Next set of package(s) would be the main imagery ones like
tiff/gif/jpeg/png, or would these be rolled into the base package?
Further out still then you have GDAL, COLLADA.
Then we have the specialist plugins that depend upon Inventor,
libxul/gecko, libVNCServ, Svgr/Cairo, Cairo/Popper, OpenVRML (and an
out of date version at that...).
Further down the line I would like to see an osgAudio library
integrated into the core OSG, this may well directly depend upon
OpenGL, and as such would this make OpenAL a core dependency, or just
have it made as a none core dependency with a separate package for
it.
Orthogonal to these dependency based packages, I am think that the
osgIntrospection and osgWrappers are probably something that could be
its own package, as the osgWrappers are extremely large, larger than
the core libraries themselves, so placing them in a separate package
that only users that need them would pull in.
My expectation is that we probably won't be able to roll out packages
for all the different possible major dependencies, and in these cases
users will just have to grab the OSG sources and download there own.
I don't have a problem with this - as long as we have base packages
that most users can grab and use in their applications I'm happy. We
might want to make it possible for users to match these extra modules
with the standard distributed packages that they plan to build upon,
although this might just be more awkward than it's worth...
As I mentioned earlier I would like to get a scheme together for 2.8,
and get this rolled out soon, I would have like this month, but
someone seems to have stole all the days of November so we don't have
time left to make 2.8 this month, but we absolutely should get 2.8
out
the door before the Christmas break. I'd all like to get next years
round of linux distro's using 2.8 rather than out of date versions of
the OSG (Kubuntu 8.10 has OSG-2.4 which is stable release behind us).
So please engage on this topic. Tell me what packages you'd like to
see. Also if you can help out making the packages, what elements to
the OSG could be done to make your life easier?
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
