Re: GLee 5.5

[Miriam Ruiz <miriam@debian.org>]

I've packaged the latest release from git in the least intrusive way
(upgrading the SONAME, in any case).

It is already uploaded to svn and alioth, in case someone wants to
give it a glance. I would be glad to have a review of the package, if
someone had time.

Thanks,
Miry

2014-04-18 0:29 GMT+02:00 Vincent Fourmond <fourmond@gmail.com>:
> On Fri, Apr 18, 2014 at 12:12 AM, Miriam Ruiz <miriam@debian.org> wrote:
>> 2014-04-17 23:58 GMT+02:00 Vincent Fourmond <fourmond@debian.org>:
>>>   Hi Miry,
>>
>> Hi!!
>>
>>> On Thu, Apr 17, 2014 at 11:38 PM, Miriam Ruiz <miriam@debian.org> wrote:
>>>> While packaging Löve 0.9.1 I've noticed that they embedded the version
>>>> 5.5 of GLee so the one in the system doesn't work anymore. Googling
>>>> about it, I found that other projects have done it too, but while
>>>> looking for it, I only find GLee 5.5 in SVN, it has never been
>>>> released.
>>>>
>>>> I'm planning to upoad Löve with the embedded GLee for the moment,
>>>> until I decide what to do about GLee, as I'm not sure I want to
>>>> package something not released
>>>>
>>>> Thoughts?
>>>
>>>   Here are mine, I probably wouldn't even give 2 cts for them. Nothing
>>> stops you from packaging a SVN version of GLee at the moment, with an
>>> appropriate name, such as 5.5~svn+r288734. Just make sure it can be
>>> replaced by the "real" 5.5 version later should upstream choose to
>>> release it. In any case, you should point the problem to upstream of
>>> GLee.
>>>
>>>   One last trick question: is the 5.5 version of GLee embedded in Löve
>>> just a SVN snapshot, or did it get modified ?
>>
>> Hi,
>>
>>
>> I't probably more difficult than that, now that I look at the header file:
>>
>> * [This file was automatically generated by GLeeGen 7.0
>>
>>
>> GLeeGen seems to be here:
>>
>> http://sourceforge.net/p/glee/glee/ci/master/tree/
>>
>>
>> Probably the way to go would be packaging GLeeGen from GIT, removing
>> the GLee package, build-depend stuff on it,...  damn, I have to think
>> about it.
>
>   Hmmm I don't think you want dynamically generated code integrated
> statically into each package that depends on this code: it would be a
> very hideously hidden code duplication -- a nightmare securitywise as
> far as I can tell. I'm seeing that from quite far away, but, maybe,
> the best way to go is to package gleegen, and have the gleegen package
> run itself at build-time to generate a dynamically built glee library,
> that would be part of the gleegen source package too. This way, you
> remove all code duplication, you just have to follow gleegen. The
> downside is that the build process may turn out to be a tidbit
> delicate.
>
>   Cheers,
>
>       Vincent