From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-March/013728.html | 93 +++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-March/013728.html (limited to 'zarb-ml/mageia-dev/2012-March/013728.html') diff --git a/zarb-ml/mageia-dev/2012-March/013728.html b/zarb-ml/mageia-dev/2012-March/013728.html new file mode 100644 index 000000000..38432468a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-March/013728.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Removal of sun java + + + + + + + + + +

[Mageia-dev] Removal of sun java

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Fri Mar 30 16:03:14 CEST 2012 +

+
+ +
Le 30/03/2012 15:25, Christian Lohmaier a écrit :
+> If that is not reading: Don't push the security updates to the users,
+> let the user take care of that manually, then what else?
+That just means 'give the end user everything he needs to take a 
+decision (advice, notification, packages, popup, whatever) but let him 
+take this decision about this specific issue himself'.
+
+Let's try to move toward a consensus...
+
+Mixing removing of sun jdk with updating another jdk for security seems 
+an unfair bundle, as you can't have one without another.
+
+Issuing a specific sun jdk security update package, containing only a 
+README.urpmi file and a shell script inciting the user to read this file 
+eventually, would be a fair compromise for me. And can be considered as 
+a standard practice for semi-automatically removing 
+very-dangerous-packages-we-cannot-afford-to-let-installed-anywhere-otherwise-the-apocalypse-will-happen.
+
+-- 
+BOFH excuse #8:
+
+static buildup
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1