| |||||||||||||
Move to a portable app modelMove to a portable app modelPosted Jun 7, 2006 21:38 UTC (Wed) by madscientist (subscriber, #16861)In reply to: Move to a portable app model by nlee Parent article: The problem of Firefox in Ubuntu Breezy
Well, the extensions library is actually a good example of why they don't want to upgrade (if it's included in the package): anyone who's written any extensions to the 1.0.8 FireFox for Debian stable will surely be P.O.d if a "security update" installs a major version upgrade of FireFox which breaks all of her work that depends on the older version. It's exactly these sorts of situations that the stable policy Debian/Ubuntu have are designed to guard against. As for the prerequisites for the package, it's not a problem for a package to have a lot of prerequisites per se. It's only a problem if either of two things is true: (a) other packages depend on the to-be-replaced package, since that means they all must be upgraded as well. I don't think FF is in this category. Or (b), the new version of the to-be-replaced package requires some new support libraries or it won't work anymore, since that means you have to upgrade all those prerequisites first. I'm pretty sure even FF 1.5 will build OK with the versions currently in Debian Stable/Ubuntu Breezy. You won't have to upgrade all those packages (and everything they depend on, etc.)
(Log in to post comments)
Move to a portable app model Posted Jun 7, 2006 21:44 UTC (Wed) by h2 (guest, #27965) [Link] Easy enough to test, install tarred firefox 1.5 on debian stable, if it runs fine, that's the answer. I might try that in the next few days to see, I've been wanting to do a debian stable or etch install anyway, might as well do both and see how that stuff works. My guess is firefox will install fine as a tarred thing, maybe not the deb, but that's easy to see too by a simple apt-get install firefox -s test.
The extension thing is another matter, but at some point you have to adapt yourself to that situation, every single new version, 1.5.3->1.5.4 for example, can break an extension, extension compatibility is tested every time you upgrade version no matter what.
Very few extension developers pay much attention to older versions, and it's up to them and only them to do that, there's no way anyone else could handle doing extension backward compatibility testing, that's not realistic, and won't happen. You're much better off using the latest firefox, with its glitches, especially if you use extensions heavily, but most people don't do that.
Move to a portable app model Posted Jun 9, 2006 12:40 UTC (Fri) by louie (subscriber, #3285) [Link] "Easy enough to test, install tarred firefox 1.5 on debian stable, if it runs fine, that's the answer."
hahahahaha. That's such a ... charmingly naive approach to QA. What about:
You have to test all of those too. And 'testing' something that depends on a browser is a hit or miss thing, given that a browser is so large.
All of the major distros are going to have to have a chat with moz.org at some point if they see themselves as seriously doing long-term desktop support, because it is clear that moz.org doesn't realize how deeply flawed their support policy is for those distros. Ubuntu is just the only one having this discussion in public right now.
Move to a portable app model Posted Jun 9, 2006 19:42 UTC (Fri) by h2 (guest, #27965) [Link] so how much are those distros contributing to mozilla to get that long term support? With the exception of debian, we are after all talking about for profit corporations here. So if they want that type of support, I suggest they get together and create a few staff positions at mozilla.com whose sole role is maintaining old mozilla/firefox versions.
If they don't want to pay for this, then their feelings on this question are fairly irrelevant. And what would that cost, tops? To maintain security patches for a handful of gecko based browsers? Probably one person could do it, so between redhat, suse, mandriva, etc, what are we talking about to get this desired security patch support? $10,000 a year? Maybe 20k if they hired two people?
This isn't very hard to do, if you need something done that nobody wants to do, pay someone to do it. And if you need it done, for reasons of corporate network stability, then pay for it. This isn't complicated.
If redhat/suse/mandriva can't afford to pay this pittance then they are in the wrong business and should contemplate entering into a new line of work, maybe ice cream sales or something.
Move to a portable app model Posted Jun 16, 2006 12:28 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Actually, as I see it, since the Mozilla folks get $$ every time someone searches at Google w/ their browser, I'd say the fact that distros choose to make Firefox their default browser is payment enough.
Move to a portable app model Posted Jun 7, 2006 21:51 UTC (Wed) by nlee (guest, #730) [Link] You make a very valid point. One response might be, how do we know any backport feature don't break the current set of firefox extensions in the debian archive?
It is a hard choice for Debian. The "unknown" security fixes in the latest and probably forth coming Firefox versions, make things very difficult. I guess this is one of the reasons I prefer Ubuntu for the desktop. They have a tight release cycle.
Move to a portable app model Posted Jun 7, 2006 21:55 UTC (Wed) by h2 (guest, #27965) [Link] Not to sidetrack, but this is why I prefer kanotix, it's a direct access to sid, usually not much more than a week goes by before I have the latest tbird or firefox, but at the cost of being in an unstable pool. And it's unstable, no doubt.
The same problems, by the way, exist for konqueror, kmail, to upgrade those you have to upgrade all of kde, so it's actually worse than firefox/tbird.
But significantly less people use those than firefox so it doesn't hit the news in this way.
Move to a portable app model Posted Jun 8, 2006 12:16 UTC (Thu) by jond (subscriber, #37669) [Link] The issue here is it now being impossible to separate out changes made upstream that are security fixes and those that aren't. afaik, the problem isn't the same for KDE, because they have a security policy more in-line with Debian's.
|
|||||||||||||