[Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.

Thu Aug 25 11:03:42 CEST 2011

My apologies for previously mixing up the roles of the sysadmin
+team, and the council, in asking for a decision to be made.
+
+Anyways, as I mentioned in the packagers meeting, before I had to
+leave, due to other things going on,
+https://bugs.mageia.org/show_bug.cgi?id=2317
+needs to be solved quickly, as it is blocking several other updates.
+
+I used to see "broken updates" from time to time, in Mandriva, and
+never understood how those updates could get pushed.  Now I do
+understand.
+
+The problem with the current way things are being done, is that, if
+a user tries to install an update, and that update requires a
+dependency that the user doesn't already have installed, and is the
+update is not in the updates repository, the update will fail.
+
+The problem showed up with an update to kipi-plugins-expoblending
+https://bugs.mageia.org/show_bug.cgi?id=2097
+where the purpose of the update was to add a requires on hugin.
+
+The update passed qa because I used urpmi to install it, rather then
+mgaapplet.
+
+In that case, the problem was solved by an update (really just a copy)
+of hugin, to the updates repository.
+
+I finally understood why broken updates become available.  The mgaapplet
+uses "urpmi.update --update", which will not resolve dependencies from
+repositories other then those marked as updates, in /etc/urpmi/urpmi.cfg.
+
+There are two methods to try to fix this.
+
+The Mandriva way, where all dependencies of any update also get copied
+to the Updates Testing repository, and then pushed together to Updates,
+or, change mgaapplet to use "urpmi --auto-update", instead of
+"urpmi.update --update".
+
+In my opinion, the Mandriva way is too easy to lead to broken updates.
+It lead to broken updates often enough, the half dozen "new to linux"
+people I currently support rely on me to install updates, as it's too
+confusing for them to sort out.
+
+If the packager, and the qa team already have the dependencies installed,
+they won't realize the problem will exist for users (or if they use
+urpmi, and don't pay attention to which repository the package is being
+installed from).
+
+There is also the problem with duplicating packages from Core Release
+to Updates Testing, and then Updates.  An automated solution to ensure
+all dependencies are available would effectively duplicate Core Release
+in Core Updates Testing, and in Core Updates, (and in tainted, and in
+non-free).  Determining which requires might not already be installed
+in the users system, therefore needing to be available in updates is
+not simple.  Especially while we support upgrading from Mandriva, where
+the update for a dependency may have been blocked, due to Mageia not
+yet having the package available.
+
+The problem with using "urpmi --auto-select" is that it increases i/o
+and cpu usage for every execution of the check for updates by mgaapplet.
+On my 6 year old system 5 seconds for "urpmi.update --update" versus
+24 seconds for "urpmi --auto-select", when the system is up-to-date.
+
+If the Mandriva way is kept, we must ensure all needed dependencies
+are available in Updates (Testing too).  In addition, all packager must
+be willing to copy the dependencies from Core Release to Core Updates
+Testing, and the sysadmin team must push them.
+
+If changing mgaapplet is chosen, that must be given a very high priority.
+
+Either way, a decision is needed quickly.
+
+Thanks, Dave Hodgins
+