On Mozilla-* updates

classic Classic list List threaded Threaded
131 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

On Mozilla-* updates

Joey Schulze
Moin,

it seems that less than two months after the release of sarge it is
not possible to support Mozilla, Thunderbird, Firefox (and probably
Galeon) packages anymore.  (in terms of fixing security related
problems)

Unfortunately the Mozilla Foundation does not provide dedicated and
clean patches for security updates but only releases new versions that
fix tons of security related problems and other stuff that is or may
be irrelevant for security updates.  As a result, it is extremely
difficult to get security patches extracted and backported.  This is
an utter disaster for security teams and distributions that try to
support their releases.

We have tried to prepare updated packages, but they may cause problems
as has been the case for a Debian fork.  Eventually they've given up
and released the new upstream version as security update.  *sigh*

Using new upstream versions are bound to cause new problems.  Maybe
not at the moment with only going from 1.0.4 to 1.0.6 but more
probably they will do later.

Sooner or later they will change the behaviour of the program (so uses
will be confused), change the API (so plugins, language files etc
won't work anymore), alter the dependencies (so the packages will be
slurp in new packages or cannot be built on stable at all).

I guess in the long term we're on a lost track and it seems this
situation has already started.

For these packages, help and/or advice is appreciated.

Regards,

        Joey

--
It's time to close the windows.

Please always Cc to me when replying to me on the lists.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Geoff Crompton
>
> For these packages, help and/or advice is appreciated.
>

Can we try to get a DD involved in the mozilla security team? Presumably
when they become aware of a security issue, there is some discussion
about the problem and how to fix it. Access at this level may make it
possible to identify in the code where the problems are.
Then that person could release more detailed information about the fix
after the embargo ends, which would benefit all other distributions in a
similar position.

Geoff Crompton


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Mike Hommey
On Sat, Jul 30, 2005 at 09:51:28AM +1000, Geoff Crompton <[hidden email]> wrote:

> >
> > For these packages, help and/or advice is appreciated.
> >
>
> Can we try to get a DD involved in the mozilla security team? Presumably
> when they become aware of a security issue, there is some discussion
> about the problem and how to fix it. Access at this level may make it
> possible to identify in the code where the problems are.
> Then that person could release more detailed information about the fix
> after the embargo ends, which would benefit all other distributions in a
> similar position.

Only problem beeing that mozilla team access is a meritocracy...

Mike


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Chris Adams-2
In reply to this post by Joey Schulze

On 2005-07-29, at 9:43 AM, Martin Schulze wrote:
> Using new upstream versions are bound to cause new problems.  Maybe
> not at the moment with only going from 1.0.4 to 1.0.6 but more
> probably they will do later.
...
> I guess in the long term we're on a lost track and it seems this
> situation has already started.

I'm inclined to say that it'd be better to ship the current release  
(or the earliest Mozilla-supported version for major releases) until  
these problems actually do become more work than the backports. The  
rationale is basically that the usual concerns apply less to browsers  
since they're less mission critical, people are more used to frequent  
updates (and tend to have fewer dependencies on specific versions),  
and new features are more useful because websites which use them are  
widely "deployed" independently of whatever Debian or the sysadmin do.

Given the threat exposure I think it makes more sense to stick with  
what the rest of the world is using (especially in cases where the  
fixes are not well localized), particularly since there are areas  
where the new features in point upgrades can add almost as much value  
as the pure security updates - when things like spam filters or anti-
spoofing technology improve it's frequently in response to changes in  
the attackers' behavior, which a pure back-port model can't account  
for, and that generally means that even if the old software works  
perfectly the users are going to be complaining because they're  
seeing more successful attacks. We saw this in the past with  
SpamAssassin; it pushed us to rush newer versions into production  
because the tradeoff was between the certainty of "My spam filter  
isn't working!" complaints versus a relatively low-probability chance  
of finding a backwards-compatibility bug - not a decision I'm  
entirely happy about but it's definitely proven to be the better  
course so far.

Chris

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Willi Mann
In reply to this post by Joey Schulze

> Using new upstream versions are bound to cause new problems.  Maybe
> not at the moment with only going from 1.0.4 to 1.0.6 but more
> probably they will do later.
>
> Sooner or later they will change the behaviour of the program (so uses
> will be confused), change the API (so plugins, language files etc
> won't work anymore), alter the dependencies (so the packages will be
> slurp in new packages or cannot be built on stable at all).

IMHO, sloopy security support (by uploading new upstream versions) is better
than no security support.

I'd say, 1.0.x (firefox, thunderbird) should go to security.debian.org (in
the hope that it doesn't cause other problems) because sarge users expect to
get fixed packages from there. Of course, that will need testing.

For 1.5.*, (firefox, thunderbird) it should also be put on
security.debian.org when it first fixes any security related issues, but
only as long as the only problem are untranslated strings (We can make the
langpacks available from some seperate location, if needed)

For mozilla, the problems are hopefully smaller, because 1.7.* will probably
stay more or less at it is, and new upstream versions are security fixes
plus some small bug fixes. (I have to admit that I didn't verify that claim
by looking at the source code)

For etch, mozilla packages should be supported by some seperate location
(like volatile.debian.net), and people who install desktop systems should be
asked if they want to add that location to their sources.list.

Willi


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Floris Bruynooghe
In reply to this post by Chris Adams-2
On Sat, Jul 30, 2005 at 12:32:42AM -0700, Chris Adams wrote:

>
> On 2005-07-29, at 9:43 AM, Martin Schulze wrote:
> >Using new upstream versions are bound to cause new problems.  Maybe
> >not at the moment with only going from 1.0.4 to 1.0.6 but more
> >probably they will do later.
> ...
> >I guess in the long term we're on a lost track and it seems this
> >situation has already started.
>
> I'm inclined to say that it'd be better to ship the current release  
> (or the earliest Mozilla-supported version for major releases) until  
> these problems actually do become more work than the backports. The  
> rationale is basically that the usual concerns apply less to browsers  
> since they're less mission critical, people are more used to frequent  
> updates (and tend to have fewer dependencies on specific versions),  
> and new features are more useful because websites which use them are  
> widely "deployed" independently of whatever Debian or the sysadmin do.
>
> Given the threat exposure I think it makes more sense to stick with  
> what the rest of the world is using (especially in cases where the  
> fixes are not well localized), particularly since there are areas  
> where the new features in point upgrades can add almost as much value  
> as the pure security updates - when things like spam filters or anti-
> spoofing technology improve it's frequently in response to changes in  
> the attackers' behavior, which a pure back-port model can't account  
> for, and that generally means that even if the old software works  
> perfectly the users are going to be complaining because they're  
> seeing more successful attacks.

This all just seem arguments to put the (new) mozilla browsers into
the volatile archive.  It definately is not what I thought of as
something I'd expect for the stable archive.  If we choose stable we
do so with a reason and we know what we choose.  If we add volatile
we also know what we're doing.

The problem is much harder when we can't actually have the backports.
In my opinion it's *maybe* better to just leave the browsers in
stable as they are and make an announcement to [hidden email]
or so that their security is sub-optimal or non-existing and if they
want they can use the new packages from volatile.

It is also an option to send out the DSA's about them and stress the
fact that the problems are *only* solved in testing and volatile,
*not* via the normal security.debian.org so not in stable.  Specific
instructions are included with every DSA anyway.


Just my (current) view of the situation.

Floris

--
Debian GNU/Linux -- The power of freedom
www.debian.org | www.gnu.org | www.kernel.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Florian Weimer
In reply to this post by Joey Schulze
* Martin Schulze:

> it seems that less than two months after the release of sarge it is
> not possible to support Mozilla, Thunderbird, Firefox (and probably
> Galeon) packages anymore.  (in terms of fixing security related
> problems)

This is very unfortunate and happened much sooner than expected.

Since this problem is potentially much more general (for example, it
seems that upstream's security support for PHP 4.3 has already ended),
it's better to search for a generic approach instead of a
Mozilla-specifc one.

We have to address at least the following concerns:

  * Our users need timely security updates.  If no update is available
    and vulnerabilities or even exploit code have been published, they
    should be warned.

  * When a coordinator prepares a disclosure, Debian should provide
    input on Debian's status.

  * Some packages have been abandoned by upstream and there is very
    basic security support only (e.g. BIND 8).

  * Some upstream authors do not provide specific security fixes (PHP,
    Mozilla, GNU libc).  Sometimes, no backports for the version in
    stable are available, and the packages are too complex that we can
    prepare them in a reasonable timeframe.

  * Some fixes are very invasive (because they address design issues)
    and thus impossible to backport.

  * security.debian.org is a single point of ownership.  If we push
    out a malicious security update, really interesting things might
    happen.

  * Predisclosure information is, by its definition, only available
    under a socially enforced NDA (or, increasingly, real NDA).

  * Debian's capacities are limited, and it's a volunteer-driven
    organization.

(Maybe I missed some points.)

For simplicity, I'm going to ignore the predisclosure NDA problem in
the reminder of this message.  Addressing vulnerabilities
post-disclosure is already hard enough, and the two or three weeks of
time we gain doesn't seem to be a decisive factor anyway.

The idea I've been thinking about is a two-stage publication process
for security updates.  Under this process, any DD can upload packages
to a new apt-gettable archive on security.debian.org.  Binary uploads
are not permitted, though.  DDs should exercise reasonable care when
preparing the uploads. New upstream versions are discouraged, but not
ruled out completely.  We expect that users who use this package
source know that they are essentially beta testers.  Maybe we should
call this the Debian Patch Validation Program.

The Debian security team reviews the pending security updates.  For
example, it could use exploit code it has obtained under NDA to check
if the vulnerabities are indeed closed.  These reviews also help to
ensure that Debian does not distribute a malicious security patch to a
broader audience after a developer key has been compromised.  This is
also the reason why binary uploads are not permitted.

After some time has passed and no showstoppers have been discovered by
the patch validators or the security team, the security team pushes
the updates to the real security archive.  In principle, something
like the migration to testing could be implemented.  Maybe it's
desirable to push multiple updates at the same time, on some
predictable patch day.  Certainly it must be possible to push out
emergency updates when exploits are in the wild, or other
circumstances suggest an immedate update.

Packages for which no security support is provided need to be flagged
in some way.  Maybe some of the existing scripts which relate
installed packages to bug reports could be used for that.  But this
would imply that we must exercise more care when recording security
bugs in the BTS.

As a consequence, responsibility to provide a fixed package for a
published vulnerability no longer rests with the security team alone,
but with all DDs.  In principle, this is already true today, but as
far as I can tell, our current practice does not reflect this.

I'm not sure if this plan can be implemented.  As far as I know, any
change to the buildd infrastructure is very hard to implement for
organizational reasons.  It's also questionable if we can get enough
developer support.  But in my mind, the crucial change in this new
process is the Patch Validation part, which allows us to consider
updates which are significantly more far-reaching than five-liners
fixing simple buffer overflow.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Florian Weimer
In reply to this post by Geoff Crompton
* Geoff Crompton:

>>
>> For these packages, help and/or advice is appreciated.
>>
>
> Can we try to get a DD involved in the mozilla security team?

Some of the Mozilla bugs come from deep design issues in the code.
Even if you know all the details, backporting might still be
infeasible.

What's worse, an ABI-changing patch always changes the ABI, backported
or not.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Peer Janssen
In reply to this post by Florian Weimer
Florian Weimer wrote:

>  * Some upstream authors do not provide specific security fixes (PHP,
>    Mozilla, GNU libc).  Sometimes, no backports for the version in
>    stable are available, and the packages are too complex that we can
>    prepare them in a reasonable timeframe.
>
>  * Some fixes are very invasive (because they address design issues)
>    and thus impossible to backport.
>
>  * security.debian.org is a single point of ownership.  If we push
>    out a malicious security update, really interesting things might
>    happen.
>  
>
That's why it might be good to have a second, distinct security path
("security essentially managed by upstream") (or whichever other path
will be available). Integrated in the packet management system, but
maybe with non-automatic upgrades ("New upgrades available -- do you
want package X ?"), or automatic at the discretion of the trusting user.

 From a user point of view, I'd appreciate if the debian team could
ensure that no data is lost while doing such upgrades. E.g., I'm not
sure that while upgrading from one mozilla version to the next, every
user data (profile, mail, plugins etc.) is always correctly imported. In
such a case, perhaps the team could provide the necessary conversion
scripts, urge such improvements from upstream, or both.

Peer


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Noah Meyerhans-3
In reply to this post by Joey Schulze
Most other OS vendors are willing to make updates for errata beyond
simple security updates.  Often this means minor updates to software
packages like web browsers.  I believe the community will be better able
to help us prepare e.g. bug-free firefox 1.0.5 packages than it will to
produce 1.0.4+security packages.  I believe these updated packages
should be tested as thoroughly as possible and released via
security.debian.org and included in the next sarge revision.  As an
administrator of several hundred Debian workstations, all of which
include mozilla, firefox, and thunderbird, I can say that I'd rather see
1.0.5 than see nothing at all, or (IMO just as bad) unofficial packages
distributed outside the official Debian update channels.

Whatever solution we choose, I believe it is very important for us to do
it within Debian and not rely on backports or some other unofficial
channels.  As Debian developers, it is our duty to solve this problem,
and simply kicking the packages out of Debian or ignoring them from the
point of view of updates and security is really no solution at all.

noah


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Marc Haber-9
In reply to this post by Floris Bruynooghe
On Sat, Jul 30, 2005 at 03:22:53PM +0200, Floris Bruynooghe wrote:
> This all just seem arguments to put the (new) mozilla browsers into
> the volatile archive.  It definately is not what I thought of as
> something I'd expect for the stable archive.  If we choose stable we
> do so with a reason and we know what we choose.  If we add volatile
> we also know what we're doing.

ACK.

> The problem is much harder when we can't actually have the backports.
> In my opinion it's *maybe* better to just leave the browsers in
> stable as they are and make an announcement to [hidden email]
> or so that their security is sub-optimal or non-existing and if they
> want they can use the new packages from volatile.

I would go one step further and remove vulnerable mozilla software
from stable, or put up dummy packages pointing people to volatile in
the security archive. I don't like the idea of shipping vulnerable
software and not taking measures to prevent that software from being
installed on a system with stable+security. We cannot expect our users
to read our announcements.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Joey Schulze
In reply to this post by Noah Meyerhans-3
Noah Meyerhans wrote:
> Most other OS vendors are willing to make updates for errata beyond
> simple security updates.  Often this means minor updates to software
> packages like web browsers.  I believe the community will be better able
> to help us prepare e.g. bug-free firefox 1.0.5 packages than it will to
> produce 1.0.4+security packages.  I believe these updated packages

Looking at how 1.0.5 was binary-incompatible with 1.0.4 I can only
assert that the community has failed already.

> should be tested as thoroughly as possible and released via
> security.debian.org and included in the next sarge revision.  As an

We don't have the proper framework for thoroughly testing security
updates before they are visible on security.debian.org similar to the
10 days embargo from unstable into testing.  The regular testing is
not sufficient as it can't cover all details.

> Whatever solution we choose, I believe it is very important for us to do
> it within Debian and not rely on backports or some other unofficial
> channels.  As Debian developers, it is our duty to solve this problem,
> and simply kicking the packages out of Debian or ignoring them from the
> point of view of updates and security is really no solution at all.

Be prepared for reality, in half a year or in one year, there won't be
1.0.x Mozilla Firefox packages anymore that build on Debian stable.
At least that's what I anticipate.

Regards,

        Joey

--
Experience is something you don't get until just after you need it.

Please always Cc to me when replying to me on the lists.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Jan Luehr-10
Greetings,.

Am Samstag, 30. Juli 2005 16:47 schrieb Martin Schulze:
> Noah Meyerhans wrote:
(...)
> > Whatever solution we choose, I believe it is very important for us to do
> > it within Debian and not rely on backports or some other unofficial
> > channels.  As Debian developers, it is our duty to solve this problem,
> > and simply kicking the packages out of Debian or ignoring them from the
> > point of view of updates and security is really no solution at all.
>
> Be prepared for reality, in half a year or in one year, there won't be
> 1.0.x Mozilla Firefox packages anymore that build on Debian stable.
> At least that's what I anticipate.

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.
If they are in favor with Mozilla, they can download the mozilla.org builts
and use 'em and ff mozilla.org is in favor with debian users as well, they
perhaps maintain an apt source like samba is doing now.
It's time to face, that debian has some standards in security - an in
development cycles as well.
Thus there are packages that simply don't fit into debian - not only because
of license, patent or DD issues.
The discussion we had about the woody mozilla (which is still ought to be
supported by debian security, as long as woody is supported as oldstable)
pointed out that these problems - even if forseen months ago - could not be
solved, furthermore it pointed out that mozilla doesn't fit into debian - at
least at that time.
We have to admit, history is probably going to repeat it self in this case:
The mozilla maintainers, haven't answered my mail, how they want to prevent
the woody-situation in sarge - and I doubt, that there will be a solution.

Imho, we should really face the consequences of these issues and stop shipping
mozilla.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Floris Bruynooghe
On Sat, Jul 30, 2005 at 05:38:09PM +0200, Jan Luehr wrote:

> Greetings,.
>
> Am Samstag, 30. Juli 2005 16:47 schrieb Martin Schulze:
> > Noah Meyerhans wrote:
> (...)
> > > Whatever solution we choose, I believe it is very important for us to do
> > > it within Debian and not rely on backports or some other unofficial
> > > channels.  As Debian developers, it is our duty to solve this problem,
> > > and simply kicking the packages out of Debian or ignoring them from the
> > > point of view of updates and security is really no solution at all.
> >
> > Be prepared for reality, in half a year or in one year, there won't be
> > 1.0.x Mozilla Firefox packages anymore that build on Debian stable.
> > At least that's what I anticipate.

<snip/>

> Imho, we should really face the consequences of these issues and stop shipping
> mozilla.

Or keep mozilla in volatile and not in stable.  But since mozilla is
already shipped in sarge this will be an etch issue (as I also hope
volatile will be official from etch on).  I just can't see a package
being deleted from sarge, imho the best we can do right now is send
out DSA's and point to volatile for fixes.

Greetings
Floris

--
Debian GNU/Linux -- The power of freedom
www.debian.org | www.gnu.org | www.kernel.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Bernd Eckenfels
In reply to this post by Joey Schulze
In article <[hidden email]> you wrote:
> Be prepared for reality, in half a year or in one year, there won't be
> 1.0.x Mozilla Firefox packages anymore that build on Debian stable.
> At least that's what I anticipate.

So lets solve this and release more often.

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Nikita V. Youshchenko-3
In reply to this post by Jan Luehr-10
>
> 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).


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Jan Luehr-10
In reply to this post by Bernd Eckenfels
Greetings,

Am Sonntag, 31. Juli 2005 05:09 schrieb Bernd Eckenfels:
> In article <[hidden email]> you wrote:
> > Be prepared for reality, in half a year or in one year, there won't be
> > 1.0.x Mozilla Firefox packages anymore that build on Debian stable.
> > At least that's what I anticipate.
>
> So lets solve this and release more often.

Despite of the fact, the the release is probably unable to match the mozilla
release cycles - do you really think, mozilla is the one and only package,
debian is all about? Well, I mean the killer application, the thin that
justify Debian?

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Jan Luehr-10
In reply to this post by Floris Bruynooghe
Greetings,

Am Samstag, 30. Juli 2005 23:28 schrieb Floris Bruynooghe:

> On Sat, Jul 30, 2005 at 05:38:09PM +0200, Jan Luehr wrote:
> > Greetings,.
> >
> > Am Samstag, 30. Juli 2005 16:47 schrieb Martin Schulze:
> > > Noah Meyerhans wrote:
> >
> > (...)
> >
> > > > Whatever solution we choose, I believe it is very important for us to
> > > > do it within Debian and not rely on backports or some other
> > > > unofficial channels.  As Debian developers, it is our duty to solve
> > > > this problem, and simply kicking the packages out of Debian or
> > > > ignoring them from the point of view of updates and security is
> > > > really no solution at all.
> > >
> > > Be prepared for reality, in half a year or in one year, there won't be
> > > 1.0.x Mozilla Firefox packages anymore that build on Debian stable.
> > > At least that's what I anticipate.
>
> <snip/>
>
> > Imho, we should really face the consequences of these issues and stop
> > shipping mozilla.
>
> Or keep mozilla in volatile and not in stable.  But since mozilla is
> already shipped in sarge this will be an etch issue (as I also hope
> volatile will be official from etch on).  I just can't see a package
> being deleted from sarge, imho the best we can do right now is send
> out DSA's and point to volatile for fixes.

This is not as easy as it seems.
You'll at least not be able to ship some other packages.

A bunch of packages are depending on mozilla. If mozilla is has API changes,
you might pach galeon, if there is not a clean patch for galeon - which will
probably happen, if our galeon is out of date. (Also an event, which is much
likely to happen).
 If you need a new galeon you probably need a new bunch of gnome libs as -
well. Now we're talking about a full featured, actively supported gnome in
debian volatile...

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Bernd Eckenfels
In reply to this post by Jan Luehr-10
In article <[hidden email]> you wrote:
> Despite of the fact, the the release is probably unable to match the mozilla
> release cycles - do you really think, mozilla is the one and only package,
> debian is all about? Well, I mean the killer application, the thin that
> justify Debian?

No but I think most of the desktop packages suffer from the slow release cycle.

bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Mozilla-* updates

Floris Bruynooghe
In reply to this post by Jan Luehr-10
On Sun, Jul 31, 2005 at 09:14:38AM +0200, Jan Luehr wrote:

> Greetings,
>
> Am Samstag, 30. Juli 2005 23:28 schrieb Floris Bruynooghe:
> > On Sat, Jul 30, 2005 at 05:38:09PM +0200, Jan Luehr wrote:
> > > Greetings,.
> > >
> > > Am Samstag, 30. Juli 2005 16:47 schrieb Martin Schulze:
> > > > Noah Meyerhans wrote:
> > >
> > > (...)
> > >
> > > > > Whatever solution we choose, I believe it is very important for us to
> > > > > do it within Debian and not rely on backports or some other
> > > > > unofficial channels.  As Debian developers, it is our duty to solve
> > > > > this problem, and simply kicking the packages out of Debian or
> > > > > ignoring them from the point of view of updates and security is
> > > > > really no solution at all.
> > > >
> > > > Be prepared for reality, in half a year or in one year, there won't be
> > > > 1.0.x Mozilla Firefox packages anymore that build on Debian stable.
> > > > At least that's what I anticipate.
> >
> > <snip/>
> >
> > > Imho, we should really face the consequences of these issues and stop
> > > shipping mozilla.
> >
> > Or keep mozilla in volatile and not in stable.  But since mozilla is
> > already shipped in sarge this will be an etch issue (as I also hope
> > volatile will be official from etch on).  I just can't see a package
> > being deleted from sarge, imho the best we can do right now is send
> > out DSA's and point to volatile for fixes.
>
> This is not as easy as it seems.
> You'll at least not be able to ship some other packages.
>
> A bunch of packages are depending on mozilla. If mozilla is has API changes,
> you might pach galeon, if there is not a clean patch for galeon - which will
> probably happen, if our galeon is out of date. (Also an event, which is much
> likely to happen).
>  If you need a new galeon you probably need a new bunch of gnome libs as -
> well. Now we're talking about a full featured, actively supported gnome in
> debian volatile...

Ah, I see.  Didn't realise the full waterfall effect.

> Keep smiling

Simile,
Floris

--
Debian GNU/Linux -- The power of freedom
www.debian.org | www.gnu.org | www.kernel.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

1234 ... 7