Samuel Verschelde a écrit :
Le vendredi 8 juin 2012 16:11:07, andre999 a écrit :
Sander Lepik a écrit :
08.06.2012 11:38, Samuel Verschelde kirjutas:
I re-read the backports policy, and there's a part I think needs to be
pointed out before people start to backport packages.
"We need to ensure that upgrades never fail: cauldron must always have a
higher version/release than in stable releases."
This statement is true, but implies more than what it says. It means
that we can't backport a package for Mageia 1 with a higher version
than what we have in Mageia 2 release (and updates?) media. And this,
until we are able to take backports into account during upgrades.
Example :
- Mageia 2 has wesnoth 1.10.2 in core/release
- Mageia 1 can't get a higher version in its backports media
Do you all agree with my understanding of the policy ?
I see your point.
In most cases, a backport for mga1 would be essentially identical for
mga2 (except package file name and corresponding changes in the spec file).
It would only differ if dependancies differ, which I suspect is unlikely
for wesnoth or most other games, for example.
So this means that for a backport to mga1, we should first do one to mga2.
This would more than likely be done at the same time by the same
packager, so not much more work.
The demand for backports to mga1 is not likely to be very high, and
would depend on a willing packager.
I think you missed my point. If Mageia 1 "backports" has higher versions than
Mageia 2 "release" (not backports), upgrade can fail because currently our
tools do not take backports from the target release (mageia 2) into account
when upgrading a distro.
Samuel
But wouldn't current tools update backports if backports are active ?
(At least in an update after the release update. Personally I alway do
an update step after a release update, as I never have a reliable
connexion during a release update, which I do from dvd.)
This reinforces my idea that all backports should be tagged as
backports, and the tools adjusted for that. Then backports could be
updated during the release update, instead of as a separate step afterwards.
Maybe we should hold off on backports until we ensure that all backport
packages are tagged as such.
See my comment about tagging backports on the backport policy discussion
page.
This adds another factor to be considered in release updates. The tools
should be changed for this before we have any problematic backports.
Leaf packages shouldn't cause a problem, besides the package itself
maybe not working properly. In updates after the version update, the
user would see suggested updates with the current tools, as long as the
versions were appropriate, and backports were active.
--
André
