nicolas vigier a écrit :
On Wed, 27 Jun 2012, andre999 wrote:
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.
And how do you check that it is compatible, without testing ? And how do
you test that it will be compatible with a newer release that is not yet
released ?
You split in the middle of the point. (The above sentence could have
been better worded.)
See below.
Maybe we can also require that backports are bugfree, so we don't have
to manage backport updates.
That would be nice, if you can see how to do it :D
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.
We cannot link a program with both libsomething.so.1 and
libsomething.so.2.
If the spec file requires cannot be adjusted to accept linking with
whichever of the 2 is available, then in that case the backport wouldn't
be accepted - if my suggested restriction is 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.
A lot of requires are generated automatically, we cannot change them
(and changing them would probably be wrong). And a lot of requires are
not versionned, but implicitly require the version available in the
same mageia release, without any guaranty that it works with a different
version.
You mean generated automatically in the spec file ? Surprising.
If the require isn't versioned, since it would work in cauldron, and
also works in the backport release, then I would expect that it would
work in interim releases. If it doesn't, that is in the risk of a backport.
Don't forget, my suggestion is to increase the _probability_ that a
backport will work in interim releases. Not to garantee that it will.
In my experience, it is essentially the unavailability of required
packages that makes a package from an older release stop working. A
backport would fit in this mold, except it will be a variation of what
is already working in cauldron.
Collectively we may think it is not worth the increased reliability of
backports, but I think that for little effort we see an important gain.
--
André
