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