On 12 November 2011 09:32, Stefan Potyra <email@example.com>
Sure. First off, there are actually two things that could be done upstream wise:
On Fri, Nov 11, 2011 at 02:08:39PM +1300, Ishmael Turner wrote:
> If you or the games team find you don't have enough time is there anything
> I could do to help?
trigger ships copies of both libglew and tinyxml. From a distribution point of
view, we should use the shared libraries from the distribution instead.
Of course you may not want to do this from an upstream POV. What I added some
time ago to the Debian package is a patch (debian/patches/10_system_glew.patch)
which is halfway there to add a configure switch with which building against the
shared library of libglew can be selected. Maybe you'd like to pick that up and
refine it so that trigger defaults to the shipped library unless overridden to
build against the shared library? Btw. my bad for never finishing it and
committing upstream :(.
Such a switch for tinyxml would also be very helpful. Granted, last time I
touched the trigger packaging, libtinyxml in Debian was still a bit in a flux
and hat its problems, so building against it was not the best idea. Hope that
this has changed nowadays.
OK, I was planning to look at a few build bugs so I'll add using the system libraries for GLEW and Tiny XML to my list. I believe there is also PhysFS embedded in there somewhere. Perhaps I could look at providing Autotools style --with-lib options to configure for people who need to override the system libraries.
>Oh, anything you've got would be a good starting point. Btw, the packaging
> I managed to hack the existing packages to build 0.6.0 but greatly
> multiplied the Lintian warnings in the process. It seems that packaging has
> a bit of a learning curve!
is stored in svn at
I'll have a look, I may have deleted my attempts at packaging, because of the mess I made in the Debian directories. If I still have something how would you like it? Would a tarball of the Debian directory sent to this list be OK?