Thomas Backlund a écrit :
andre999 skrev 27.6.2012 14:40:
Thomas Backlund a écrit :
andre999 skrev 27.6.2012 10:47:
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).
Point is what if you backport version 14 to mga1, and mga2 has version
13, then upgrade path breaks.
No problem. If the requirements of version 14 are present in mga2, then
the backport will (very likely) continue to work normally. If the
versions of the required packages change, they will be updated with the
upgrade. Since version 13 of mga2 is less than the version 14 of the
backport, it won't be installed.
If by chance the newer versions of the required packages don't provide
all the functions required by the backport, which is possible, then the
backport will not function completely, or maybe not at all. This is a
risk of the backport, but by restricting backports to those for which
required packages are present in subsequent releases, we lessen this
risk, relative to no such requirement.
We could say that backports will "likely but not necessarily" work after
a release upgrade.
--
Thomas
--
André
