James Kerr a écrit :
On 10/06/11 15:09, James Kerr wrote:
On 10/06/11 13:54, Michael Scherer wrote:
Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
Thomas Backlund<t...@mageia.org> schrieb am 10.06.2011
So the path would then be */updates_testing -> */updates _if_ we
decide that's the way to go...
As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.
He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.
Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.) A selected backport can then be installed, without enabling
the backports source. (I've just tested this on mdv 2010.0, the only mdv
system that I have available.)
I've just realised there is a potential problem with this. Because
Mageia has /backports_testing repo's (mdv does not) packages from
/backports_testing may also be displayed. Mgaonline is updating those
sources.
Jim
That was a bug in rpmdrake.
If you had updated the repos with backports media enabled, when the backports media was
subsequently disabled, the previously available backports packages remained displayed/installable.
But new backports were not added if the repos were updated with backports disabled. There was
the same problem for other media (like non-free).
Otherwise enabling/disabling backports (or any other media) wouldn't make any
sense.
--
André
