[Mageia-dev] Missing packages in Mageia 1. How to backport?

Fri Jun 10 13:57:54 CEST 2011

Wolfgang Bornath skrev 10.6.2011 14:44:
+> 2011/6/10 Michael Scherer<misc at zarb.org>:
+>>
+>> We have used backports in the past for that, and I see no reason to
+>> change that.
+>>
+>> If the problem is that backports were too buggy in the past, then we
+>> should fix backports process, not bypassing them.
+>>
+>> And if we start by pushing new version in update, people will soon
+>> wonder why the new version of X is in updates, while the new version of
+>> Y is not, just because we didn't have X in release and Y was there.
+>
+> Problem I see:
+> So far (in Mandriva), example:  we have used 2010.0/main/backports to
+> offer new versions of software which had an older version in 2010/main
+> but the newer version in 2010.1/main, or as the name says: backporting
+> a newer version of a software from the current release to a previous
+> release, as often used for Firefox.
+>
+> For Mageia it means, /backports should hold backports of software
+> which has an older version in 1/core but a newer version in cauldron.
+> If we put new software (aka missing packages) in /backports and the
+> user activates /backports he also runs the risk that existing packages
+> of his stable installation will be replaced by real backports of newer
+> versions, backported from Cauldron - which he may not want to do.
+>
+> I wonder why we do not put these "missing packages" in /testing and
+> after a while in /core or /non-free or /tainted (wherever they
+> belong). These packages are software which were supposed to be in
+> /core or /non-free or /tainted, they were just forgotten|came too
+> late|whatever for Mageia 1 release freeze.
+>
+
+well, media/*/release tree is frozen, so _nothing_ new goes in there.
+
+So the path would then be */updates_testing -> */updates _if_ we decide
+that's the way to go...
+
+Problem is that a "missing" package introcuced in updates also can 
+introduce regressions with wrong obsoletes/provides or %pre/%post scripts.
+
+So it has to go through the same qa as the rest of the stuff heading for 
+*/updates
+
+So question becomes, do we have enough qa/security people to make it work ?
+
+And if we introduce "filtering" on what goes in and what does not,
+then who decides ?
+
+--
+Thomas
+
+