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
Regards,
Bart Martens
Attachment:
signature.asc
Description: This is a digitally signed message part