diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005978.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005978.html | 195 |
1 files changed, 195 insertions, 0 deletions
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 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Update of backport, policy proposal + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C1308874503.22020.169.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006090.html"> + <LINK REL="Next" HREF="005989.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Update of backport, policy proposal</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C1308874503.22020.169.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Update of backport, policy proposal">misc at zarb.org + </A><BR> + <I>Fri Jun 24 02:15:03 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006090.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="005989.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5978">[ date ]</a> + <a href="thread.html#5978">[ thread ]</a> + <a href="subject.html#5978">[ subject ]</a> + <a href="author.html#5978">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>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 ( <A HREF="http://www.freshports.org/ports-mgmt/portaudit">http://www.freshports.org/ports-mgmt/portaudit</A> ). 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 + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006090.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="005989.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5978">[ date ]</a> + <a href="thread.html#5978">[ thread ]</a> + <a href="subject.html#5978">[ subject ]</a> + <a href="author.html#5978">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |