Re: On Mozilla-* updates
Greetings,
Am Sonntag, 31. Juli 2005 08:57 schrieb Nikita V. Youshchenko:
> > 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.
So, you really think, the must to install mozilla form external sources
restrict their users in their everyday life?
There a a lot of distributionen out there and debian stable is certainly not
targeting newbies like Knoppix, or suse is doing.
> 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.
Of cource, it will - at least, it won't hurt most of them.
Debian ships a *dangerous* mozilla, putting the user in *danger* without a
warning.
If debian stops shipping mozilla, theses are won't be in danger anymore.
> Users will have to install packages themselves
> from different sources,
Yes.
> and manually check for new security problems;
As they have to do now. So is it a problem to follow mozilla-sec-announce, if
you're following debian-sec-announce already?
> in
> many cases this will result in vulnerable packages kept untouched.
Really? The current situtation will do as well. Furthermore, it keeps packages
untouched, even if users care about security and read debian-sec-announce
daily!
> 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').
Well wait, these user's already have this kind of problems. Debian is unable
to ship a correct mozilla - as proven in woody.
We'll avoid putting in danger, when we tell them, we won't ship mozilla for
security reasons.
> 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.
There won't be _any_ Debian solution with the current mozilla.org policy.
Debian simply cannot extend lifetime from months (or weeks as we've seen) up
to years, if the mozilla project is _unable_ to do so as well.
> 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],
Well, well, well, you cannot just put upstream versions into stable as you
might to with unstable. That's quite naive.
> (2). If binary incompatibility is detected,
... which is most probably going to happen...
> these packages should conflict
> with incompatible versions of all packages in Debian that depend on
So you provide mozilla, but throw out other packages away? I see no reason for
doing so. You argue, that removing packages from will hurt users and should
not be done.... now you are doing same.
Even if you don't consider removing them for long term, at this moment these
packages will depend on mozilla and conflict with mozilla at the same time.
And even if you put in some mozilla-firefox-1.0.6-1uptrream packages, which
will turn into an mozilla-firefox-1.0.6-1-upstream-tested package after some
weeks, users will be more confused than just telling them, they have to find
a mozilla distributor on their own.
> packages being uploaded, and a compatible version of these packages should
> be uploaded to the same location.
That I'll might lead to the scenario I pointed out already. You might going to
have two different versions of gnome in stable, maintained at the same time.
Consider the chaos and amount of work.
> (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).
I don't think, that this is going to work.
Keep smiling
yanosz
Reply to: