Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Harald Sitter]

On Fri, Aug 22, 2014 at 9:14 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2014-08-22 08:25, Harald Sitter a écrit :
>
>>> That is one good reason to generate the cache at build time, where any
>>> problem
>>> can be detected early on. Crashing during dpkg postinst script is much
>>> worse.
>>
>>
>> || true?
>
>
> Then there will be no cache, and you are not solving the problem you want to
> solve.

True enough, that still beats having a bogus cache 100% of the time
though. So, if it is waiting 3 years for someone to do the proper fix
vs. getting a not 100% reliable fix now, I'll go out and say that not
having stuff explode for the next 3 years is a viable option.
All that being said perhaps the more interesting bit is why exactly
VLC thinks the cache is invalid to begin with. In particular
considering we only have one build that builds with all plugins we
have packaged and there are no third party plugins in any package
anywhere ever. So the cache should always have a superset of what is
available on a system.

>> I fail to see how exactly the additions could make the maintainer
>> scripts fail to be honest, other than having a broken cache-gen which
>> surely is the sign of a much deeper problem that should not have
>> gotten beyond build time to begin with.
>
>
> Experience has shown that changes to certain libraries causes the cache
> generation to crash, and the maintainers of those libraries do not test
> against VLC before uploading to Debian. I mean glib, gobject, Qt, GL, libav
> to name the obvious ones...

How does that work? Wouldn't that also defunct the plugins themselves?