Le 2014-08-22 11:24, Harald Sitter a écrit :
On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont
<r...@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?
You tell me; I have never reproduced the alleged crash.
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?
It can't, unless something mucks with the modification time or some
data corruption happens.
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.
For a dedicated installer, I would agree that failing to install
straight up is better than failing to run later.
But we are talking about the Debian packaging system here. Failing to
install means screwing up the whole oeprating system.
--
Rémi Denis-Courmont
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
