nicolas vigier a écrit :
On Wed, 27 Jun 2012, andre999 wrote:
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.
There is no guaranty that requirements of version 14 mga1 backports are
all available in mageia 2. If it is linked with libsomething.so.1, but
mageia 2 only has libsomething.so.2, then there is a problem.
That was my point.
I was suggesting that it be required that backport requires be
compatible with newer releases.
In your example, cauldron would probably require the libsomething.so.2,
so if the backport requires could be adjusted to work with
libsomething.so.1, we would keep the requires compatible with
libsomething.so.2. If that isn't possible, then it wouldn't be accepted.
I'm no expert of course, but it seems to me that it would be generally
possible as long as there weren't important code changes made to make
the backport work.
So it would largely be a question of appropriately adjusting the
specified requires.
--
André
