[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

long term solution for flashplugin-nonfree in stable

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.

> 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* to* 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.

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

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


Bart Martens

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: