Thomas Backlund a écrit :
andre999 skrev 27.6.2012 10:47:
Thomas Backlund a écrit :
Thomas Backlund skrev 26.6.2012 22:25:
And then the questions we need to decide on:
(substitute mga1/mga2 for any future release...)
1. Do we support backporting package with higher version
than package in the following next mageia release has ?
(meaning if mga1 has v12, and mga2 has v14, is it ok
to backport v16 to mga1?)
* PRO: more uptodate package in backports
* CON: can cause trouble during distro upgrade
* imho both technically ok as long as we make sure
its documented so people know what to expect.
2. If one want to backport a package to mga1, does it mean
it must be backported to mga2 in order to preserve
upgrade path (unless already in mga2, depending on
question 1)?
And since we can continue this what/if discussion forever,
and thereby delay backports even more here is my take on it:
my suggestions to decide on question 1 and 2:
1. backporting bigger version to mga1 than mga2 has is
allowed as it will otherwise restrict backporting
too much. (and since its leaf packages, it should
not break (too much)). Lets just make it clear to
everyone using backports.
2. we cant really require that as the one backporting
the package to mga1 has to backport it to mga2 too
as he/she might not be using mga2 at all. if someone
wants/needs the backport for mga2, they need to
request that. (in reality, going by how backports
got handled in mdv most backports will end up in
all supported releases anyway)
I would favour adding the requirement that the dependancies of the
backport must be available in the next release. So that we would expect
This is esentially stating that we cant backport any bigger version to
mga2 /backports than mga3 will havein /release wich means when we hit
version freeze for mga3, it also freezes mga2 /backports...
I'm not following this point.
What I mean is that if backport xx for mga1 requires yy version 12 in
mga1, but yy is version 13 in mga2, we would define the requires for yy
to accept versions 12 to 13 (or maybe wider).
If the user updates to mga2, yy would be updated to version 13, and the
backport would still be expected to work (without being tested). Of
course it is possible that it doesn't for some reason, as it hasn't been
tested. But adding this requirement makes it much more likely to work.
If there is a further update to mga3, the backport would be replaced by
what was the cauldron package, which would have the appropriate requires.
that the backport would continue to function properly on an update to
the next release, but we don't require that it be tested, so it may not.
-ENOTCOMPUTE
"continue to function properly" vs "don't require that it be tested"
See my explanation above.
This is a relatively simple to check, so it won't have a big impact on
QA, but should increase significantly the reliability of backports.
Nothing is "simple" if it's supposed to "continue to function properly"
as it then must be tested.
My point is simply that if we ensure that the backport requires match
what is available in the next release, then it is more likely to work
than if we don't meet this condition.
I'm not saying that it "must" continue to function properly, only that
it is more likely to.
There are many cases where the available packages change, and it
required packages are no longer available, it could be more prudent to
deny the backport.
Just a suggestion.
If we can agree on this as a start, we can open backports
soon so we get actual facts of how backports policy and
process works.
Then we rewiew backports policy and process in ~6 months,
and adjust it if needed.
Comments? Questions ?
I would favour tagging backports as update repos, so that in the event
of a newer backport for security or bug fixes, that it will be
automatically presented with other updates.
No.
as the update applet currently works it would show the backport as
an update even if you dont have an earlier backport installed,
defeating the purpose of having separate /updates vs /backports
This is conditional on first modifying the update tools, as suggested next.
A backport should only update an already installed backport.
(Similarly for nonfree and tainted, if that is not already the case.)
This would require some modification to update tools, so it seems to me
ok to open backports beforehand, with the understanding that the update
tools would be changed to accommodate this.
Tools must work before the backports repo affect them.
I agree that it would be very much better to modify the tools first.
Just suggesting that as an alternative, if we are in a hurry to open
backports.
--
Thomas
--
André
