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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.09.26.11.35...@gmail.com
