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

Harald Sitter apachelogger at ubuntu.com
Fri Aug 22 08:24:12 UTC 2014


On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2014-08-22 10:31, Harald Sitter a écrit :
>
>> 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.
>
>
> Changed file name, file size, or file modification time.

But how could either of those happen if the only supplier of plugins
are the VLC packages and so all of the cases you mentioned should be
reflected in a new cache file provided by a new version of vlc-nox?
Or more to the point... how could a completely new installation with a
matching version of vlc-nox and vlc end up thinking the cache is
invalid?

>>>> 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?
>
>
> VLC would probably crash too, but a crashing program is not as bad and as
> likely to be reported as a crashing installation procedure.

I think installation aborting if the cache generation actually doesn't
work because of ABI breakage or whatever in an underlying library
seems like a very appropriate course of action given that all libvlc
applications would potentially end up broken at that point. It's not
the libvlc applications that are broken, so willingly letting them
crash rather than making sure we end up with a working set of plugins
+ cache seems ill-advised at best. Alas, this can be argued back and
forth, it sounds like a less than optimal situation to begin with.



More information about the pkg-multimedia-maintainers mailing list