[Mageia-dev] Update of backport, policy proposal

Fri Jun 24 22:40:46 CEST 2011

Michael Scherer a écrit :
+>
+> 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.
+>
+
+
+-- 
+André
+