Re: long term solution for flashplugin-nonfree in stable
Bart Martens wrote:
> On Wed, 2007-12-19 at 23:34 +0100, Luk Claes wrote:
>> Scott Kitterman wrote:
>>> On Wednesday 19 December 2007 12:06, Holger Levsen wrote:
>>>> Hi,
>>>>
>>>> I would like to know what the stable release managers plan to do regarding
>>>> flashplugin-nonfree in etch.
>>>>
>>>> As I see it, there are three options:
>>>>
>>>> 1. do nothing, keep a broken package in etch
>>>>
>>>> 2. remove the broken package from etch
>>>>
>>>> 3. request another upload, as the version currently in stable-proposed
>>>> updates has broken since it was uploaded (which was before r1)
>>>>
>>>>
>>>> Additionally I would like to ("officially") ask the volatile team about
>>>> their opinion of including flashplugin-nonfree in volatile/contrib. As I
>>>> read the requierements for volatile, the package fully fulfills them. (The
>>>> package is rock stable and just an installer for (the latest) nonfree flash
>>>> (from adobe) - so it does exactly what the users expect.)
>>>>
>>>>
>>> The new Flash is *known* to break konqueror but works as intended on
>>> FireFox, the reason for this is konqueror does not support XEmbed. For a
>>> stable distribution, I'm not sure what the best solution would be.
>> I would go for 2
>
> Yes, I agree about removing broken packages.
> http://lists.debian.org/debian-release/2007/12/msg00088.html
>
>> if there is an updated version in volatile we point
>> people at in the Release Notes.
>
> I'm not convinced that the typical updates of flashplugin-nonfree should
> go via volatile. Updating flashplugin-nonfree from 9.0.48.0.* to
> 9.0.115.0.* involves a new release of closed source software, so it can
> include surprises that are very not welcome in Debian stable. Volatile
> is meant for fast/frequent/safe updates, for example for updating data
> for spam filters or virus scanners. Anything in volatile should be
> (almost?) as safe as stable.
> http://www.debian.org/volatile/
>
> If we consider volatile-sloppy, even then we should keep in mind that
> this won't work for every update of the Adobe Flash Player in the
> future, because sometimes newer shared libraries might be required -
> libraries that are in testing and unstable but not yet in stable. So
> then users of Debian stable would never be sure that their sources.list
> guarantees completeness regarding flashplugin-nonfree. So even
> volatile-sloppy is not the long term solution I'm looking for, for
> flashplugin-nonfree in Debian stable.
>
> The approach that is, in my opinion, closest to reality, is to maintain
> flashplugin-nonfree in unstable, allow it to enter testing, keep
> flashplugin-nonfree out of stable and oldstable, and maintain a working
> package of flashplugin-nonfree for Debian stable at backports.org .
> Then users of Debian stable can edit their sources.list once and then
> forget about flashplugin-nonfree.
>
>> We should also mention that it breaks
>> with konqueror and maybe describe what to do in the case people want to
>> use both konqueror and a fixed flashplugin-nonfree. I would use a
>> versioned conflicts in the latest flashplugin-nonfree if it doesn't work
>> with the konqueror in stable btw.
>
> This feels like regression that should be avoided in stable thus also in
> volatile. I think that volatile means fast/frequent updates for Debian
> stable but not risky updates.
>
>> It would be good if someone could make sure the newest version (with the
>> conflicts) gets accepted in volatile and file a bug against
>> release-notes including a patch IMHO.
>
> At this point I'm not convinced that uploading flashplugin-nonfree to
> volatile would be the best approach.
>
> Much more important, in my opinion, is that the security problem for
> Debian stable is not yet solved. See possible approach number 2 in this
> message:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432755&msg=40
>
> If that approach number 2 is not acceptable for some reason, then please
> at least remove the old versions of flashplugin-nonfree from the
> archives, to prevent users wasting time on trying to install these
> packages.
> http://lists.debian.org/debian-release/2007/12/msg00088.html
Approach number 2 is worse than removing the package and having an
explanation in the Release Notes IMHO as it would look like it was still
installed...
Cheers
Luk
Reply to: