Re: iceweasel based on firefox 6.0 for squeeze
On Mon, 26 Sep 2011 00:16:04 +0100, Brian wrote:
> On Sun 25 Sep 2011 at 20:02:22 +0000, Camaleón wrote:
>
>> I think that's not comparable with a browser functionality that is
>> needed for almost 50% of today's most used sites... how many people
>> uses sort every day and how many people uses Iceweasel every day? :-)
>
> I wasn't comparing sort's functionality with Iceweasel's but countering
> the assertion that a later changed version of a program causes the
> original one to lose its usefulness. You haven't addressed this (apart
> from saying 'Yes, they do.') so it appears I've been successful in
> making my point that Iceweasel doesn't satisfy the fourth criterion for
> inclusion in squeeze-updates. :)
Hey, you can't auto-give you a point for something that I have not
discussed ;-)
Regards to the 4th point that says "a package needs to be current to be
useful" it fully fits with Iceweasel but I wouldn't say so for clamav.
ClamAV is a package focused on doing mostly one thing: detect malware
while Iceweasel is a multipurpose application because browsing involves
more activities than just rendering a page in your browser.
So while ClamAV will still be doing what it should do regardless its
version, Iceweasel won't be of usefulness when its not current.
>> If you say so... then why not keep Iceweasel 2.x branch? Let's patch it
>> "ad infinitum" to make it more secure and all happy, right? I don't
>> think so :-)
>
> squeeze-updates has nothing to do with security.
Well, let me think...
clamav was in volatile repo
volatile repo provided their own security fixes
volatile repo has been replaced by squeeze-updates
I love the logic behind the things :-)
>> ClamAV does not need to be up-to-date neither, it just need security
>> fixes. It's firmware files that keep the program useful not the program
>> itself.
>
> squeeze-updates has nothing to do with security. So which criteria does
> clamav fulfil to be there?
Clamav was on volatile repo and it received (receives) updates for
security fixes, don't know if that respond your concerns. I hope squeeze-
updates still follows that tradition (I know it does) :-)
>> We are not talking here about the need of Mozilla packages to be
>> updated (it is obvious that is something users need and for that reason
>> exists Mozilla repo and backports) but the proper repo for where to put
>> those packages.
>
> Which is why I emphasised the word 'urgently' to stress it was criterion
> number 1 for inclusion in squeeze-updates which needed consideration.
> Unfortunately it wasn't given any.
>
>> And that's the point.
>>
>> I find "squeeze-updates" very useful and most of the users will already
>> have it in their "sources.list" file but the more repos you add, the
>> more chances you have to mess things up and "forcing" the user to take
>> such decision just to get Mozilla packages updated can be overly.
>
> squeeze-updates contains a mere 33 packages derived from only 6 sources.
> tzdata may be the one many users would want updating.
Similar to what volatile repo had.
> The principal reason users want their usual archive and squeeze-updates
> in sources.list is not to lose out. With any other archive (testing,
> backports etc) they aim to gain.
What they will gain is package messing and having to deal with pinning :-)
> Mozilla packages which are not fixes for security issues rightly belong
> in the second category because they have nothing to contribute to
> keeping a stable system stable.
I guess that Mozilla new versioning system is aimed to consider
deprecated/outdated/unsupported whatever version is not their last stable
(unless they provide a separated long term branch). They have changed the
rules of the play and we have to understand -and cope with- that.
Greetings,
--
Camaleón
Reply to: