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/2011-June/005978.html | 195 +++++++++++++++++++++++++++++++ 1 file changed, 195 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005978.html (limited to 'zarb-ml/mageia-dev/2011-June/005978.html') diff --git a/zarb-ml/mageia-dev/2011-June/005978.html b/zarb-ml/mageia-dev/2011-June/005978.html new file mode 100644 index 000000000..9a2e79d93 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005978.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 02:15:03 CEST 2011 +

+
+ +
Hi,
+
+The last mail from the backport trilogy. And like all good trilogy,
+that's where the suspens is present ( as for the 1 and 2 part, you know
+there is another episode )
+
+This mail is about handling update on the backport repository. Either
+new version, or bugfix, or security upgrade. 
+
+Everybody was focused on "should we do patch, or should we do more
+backport" issue, but the real problem is not really here.
+
+First, we have to decide what kind of update do we want to see, among
+the 3 types :
+- bugfixes
+- security bug fixes, 
+- new version
+
+Then as we want to have working backports, I think we need to do test,
+like we do for normal backports, or updates. This mean someone need to
+test, besides the packagers.
+
+For the first one, we can assume that if there is a bug, someone will
+fill it. Then we can assign it to the one that backported to fix the
+packages, and ask the reporter to test.
+
+
+For the 3rd one, I guess we can use the same as 1st one. If no one ask,
+do nothing. If someone ask, do the same as others backports, and erase
+the previous one.
+
+
+For the 2nd one, it all depend on how we find out about security issues.
+A tool like the one used by debian/ubuntu that check for each package if
+the version is vulnerable or not could help packager to know if a
+backport requires a fix or not, like this is done for the others
+packages. However, this mean that someone will have to check if the bug
+is fixed, and the question is "who" ( and I do not have a answer that I
+find good enough yet ). This could even be more tricky if we consider
+that this can be a version upgrade, and a security fix. Even if we trust
+the upstream to fix the security issue, we still want to have it
+working.
+
+
+But besides this question, there is a more important problem. If we
+think that some packages updates are important enough to be sent to user
+without them asking for explicitly, we cannot let people pick only some
+packages on demand by disabling backports.
+
+Either backports source is enabled in urpmi, and this would mean that
+backports are treated like update from a user point of view, or the
+backports are enabled on demand, meaning that the user is on his own. 
+
+Again, I do not have much ideas. A solution would be to have something
+like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So
+people would be warned if the backport is insecure, or could be upgraded
+( even for a new version ). I guess we should however psuh people to run
+the latest backport, whatever the reason, to avoid headaches when bug
+are reported.
+
+Another solution would be to patch urpmi to do a special type of update,
+ie it would only update packages from backports if they come from
+backports. Not really clean, IMHO.
+
+Last solution, declare that cherry picking is not supported, or that
+people are on their own, and explain the reason. However, people have
+been asking this, and recommend this. This would also be against a goal
+of having confidence in the backports.
+
+
+Again, and as said in the title, this is a proposal so feel free to
+comment.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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