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