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

Re: On Mozilla-* updates



> 
> Well, if so, why not exclude mozilla from official debian releases? - I
> mean: Kick it out.
> Mozilla and even Galeon are not an essential parts of debian -
> alternatives exists (Konqueror, links, lynx, w3m, etc) Not shipping 'em
> will hardly restrict debian users in their everyday life.

It will.
There is a large number of sites that mozilla renders correctly, while other
listed browsers don't, especially in non-latin segment of the net. I'm
having konqueror as my primary browser, and I face this problem on regular
basis.

Moving mozilla&co out of Debian will not make situation with security of
debian installations better. Users will have to install packages themselves
from different sources, and manually check for new security problems; in
many cases this will result in vulnerable packages kept untouched. So it is
not a way of fixing security problem, but just moving the problem from
Debian to it's users - which is definitely against SC ('debian supports
it's users'). Situation is even worse because of binary incompatibilities,
and complex dependency structure of affected packages like galeon. Users
will need to have advanced technical knowledge to solve a security issue on
their systems while keeping the systems usable.

I believe some Debian-level solution is required.

If following traditional debian way (backporting security patches to stable
versions) is impossible, another way should be followed, while keeping
Debian quality standards as much as possible.

Something like the following:
(1). A new upstream mozilla should be uploaded to some location that all
stable users are strongly advised to have in their sources.list [maybe
security.d.o. maybe proposed-updates],
(2). If binary incompatibility is detected, these packages should conflict
with incompatible versions of all packages in Debian that depend on
packages being uploaded, and a compatible version of these packages should
be uploaded to the same location.
(3). If binary incompatibility is detected later (so only (1) was done and
not (2)), a new upload should happen with both (1) and (2).



Reply to: