Re: On Mozilla-* updates
Greetings,
Am Sonntag, 31. Juli 2005 20:29 schrieb Nikita V. Youshchenko:
> >> > 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 can't disagree that theoretically this is not restriction.
> However, if we go this way, logical consequence is to drop the distribution
> completely and just install everything from upstream.
Rubbish - Mozilla is some kind of special case - it combines various issues:
-It parsed and executes non-trusted data (e.g. webpages). Thus a special care
upon security has to be take.
- Mozilla is very complex - even more complex than emacs imho. Thus
backporting patches is a tough business.
- Mozilla is also used for rather sensitive thinks, like online banking,
purchasing, etc., therefore extra care has to be taken to protect it's users.
- The mozilla development cycle is rather dirty. ABI / API changes are nearly
an everyday business. (just think about the 1.0.5 / 1.0.6 issue - however, I
was still unable to install any xpis like adblock with the German built,
while the standard (English) built went fine today.)
- The mozilla roadmap is unreliable and changes rapidly. Branches, that ought
to be maintainend became obsolete, new ones were introduced and new versions
come out in a short time (compared to debian releases)
By that - Mozilla doesn't fit into debian. It's simple, perhaps hard to accept
for some users, accepted by some since woody, but obvious as well.
> Strong point of Debian is that is provides a way for users to get a
> consistent system in an easy way (and in this field it is better than suse
> or whatever, and this is the exact reason why it is better even for newbies
> - if they are going to go a few steps further than initial system
> installation).
Ok - how do you define a consistent system? Have you ever count how many
browsers are currently shipped with debian? So that's the deal? Encouraging
users to use evolution instead of mozilla mail?
Encourage them, to use konqueror, w3m, etc. instead of firefox?
I mean, we won't prevent them installing debian - they can do es they like.
> Requiring users to install an important component (which Mozilla is) from
> other sources is a bad idea in this context. I think it should not be the
> way how Debian solves it's problems.
The mozilla way of solving problems clashes with the debian way - they even
have their "You should update feature" creating an easy way for users to
update their system.
> > There won't be _any_ Debian solution with the current mozilla.org policy.
>
> Not exactly. Correct statement is, '... with the current mozilla.org policy
> AND Debian traditional way of doing things'.
> I agree with this statement.
> I see the problem.
>
> The question is - how to solve it.
> Mozilla.org policy is probably out of our control.
> However, our way of doing things is not.
Any debian solution will require massive changes in debian release policy,
development policy, etc. and will have negative side effects on other debian
components.
There are other distributions - even debian flavoured ones - which are
handling it another way - more suitable to mozilla.
> You suggest - let's stop providing mozilla (and all dependent packages).
> So packages that almost all Debian users use will go outside of Debian.
No.
For a lot users (like me) debian as _practically_ stopped shipping mozilla,
when then stopped shipping useful mozilla builts.
I'm suggesting to make clear, that debian has stopped to do so.
> I think - it is better to tune our way to do things to keep with real life
> [in form of mozilla.org policy] and still provide our users with consistent
> system with minimal effort from their side.
>
> >> 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.
>
> Why?
> What exactly makes it impossible to change our habbits and allow new
> upstream version into stable _in_ _rare_ _cases_ _when_ _there_ _is_ _no_
> _other_ _way_ _to_ _provide_ a HUGE-USED set of packages? Remember,
> "debian supports it's users"!
This _is_ happening in debian unstable. So if you - and other users - really
want to live at the bleeding edge of development, it's up to them to run
unstable.
Putting hardly tested packages in stable is insane - it'll most certainly
break other thinks.
> >> (2). If binary incompatibility is detected,
> >
> > ... which is most probably going to happen...
>
> Do you have enough statistics to make this statement?
Follow the discussion on mozilla in woody.
The binary incompatibility happend before debian was able to provide a single
DSA on the many bugs Mozilla have suffered since the release of woody.
> >> 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?
>
> Of course no. We should provide upgrades for all packages in the set at the
> same time.
>
> > 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.
>
> No. See above.
Putting a package in depending and conflicting relationship to other packages
at the same time, does mean removing the package!
> >> 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.
>
> Why thing in stable can't be just recompiled to match updated ABIs? Do APIs
> also change in incompatible ways?
Yes.
> Is galeon (and other related packages)
> upstream also uncooperative as mozilla upstream?
Yes - this is most likely to happen.
> >> (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.
>
> I think it will. At least, the opposite can't be stated before any
> estimation of needed effort was done.
Then go on and do some.
Keep smiling
yanosz
Reply to: