blind Pete a écrit :
andre999 wrote:
blind Pete a écrit :
Samuel Verschelde wrote:
Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit :
On Fri, 08 Jun 2012 10:22:41 -0400, Samuel Verschelde
<[email protected]>
wrote:
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.
In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear,
that
upgrading from a system with 2010.2 Backports was not supported. It
may work, but was not recommended.
I think we should keep the same policy for the upgrade from Mageia 1 to
2.
I.E. Don't use backports if you are planning on later doing an
upgrade, rather then a clean install.
That way, Mageia 1 users who want firefox 13 can get it, without us
having to replace the Mageia 2 iso images with an upgraded installer,
that will keep backports enabled for 2, if it was enabled for 1.
Current tools will correctly update backports much of the time. (From
my experience.)
The tools just need to be reworked somewhat to ensure that backports are
updated correctly all of the time.
Regards, Dave Hodgins
Again, this is not the policy we adopted. When we defined the backports
policy (together, although it seems most people are just discovering it
now) we said that we didn't want to have backports that don't work,
break a system, or prevent upgrade.
However, I think that for DVD upgrade without internet access this is a
sensible option. But the upgrader should detect the situation itself,
not hope that the user will read somewhere in the release notes that
it's not supported.
No, just include Cauldron's backport repositories (disabled by default)
inside the DVD iso. Upgrade to the release version, if possible.
If that is not possible, upgrade to the version in backports.
Cauldron's backport repos will always be empty.
If you introduce a new package, or a new version of an existing package
to Cauldron, it is not, by definition, a backport. Even though the same
version (not counting the revision) may be a backport for previous
releases.
By definition you are completely correct, but I was deliberatly
bending the definition to cover beta software. Or at least to
draw a distinction between an Extended Support Release package
and a standard package. A new name would make sense here.
They would have different names (if generally only the version included
in one).
Since a backport can only have one name, it would correspond to only one
of the packages. Presumably that with the same (or closest) version.
So if we do a release update to the latest release, backports will be
replaced by regular packages except in those cases where a newer version
has been introduced into Cauldron. And if we update to Cauldron, all
backports will be replaced by regular packages -- according to our
backport policy.
[snip]
Some packages annoyingly have two current versions. When that
happens it seems perfectly reasonable to just pick one, but if
anyone is ambitious enough to try two at once, this would be a
mechanism to handle it.
Don't see how backport repos are related.
To be installed simultaneously, they would have to install to different
locations, which is generally not the case. There is more than one
version of Postgresql available, for example, but they conflict and so
can't be installed at the same time.
--
André
