[Mageia-dev] Backports policy proposal

Michael Scherer misc at zarb.org
Tue Jun 28 11:46:53 CEST 2011


Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit :
> Michael Scherer a écrit :
> >
> > Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
> >> Michael Scherer a écrit :
> 
> [...]
> 
> >>> - cannot be backported if the package was just created and is thus basically untested in cauldron
> >>
> >> What about corner cases where a potential backport is incompatible with changes introduced in
> >> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
> >
> > Give a more precise example.
> 
> Suppose leaf package fooa depends on foob.  foob is part of the current release.
> Cauldron replaces foob with fooc.  fooa is incompatible with fooc.

Then why do we replace foob by it in the first place if this break
fooa ?

> fooa is requested by some users, and future versions of fooa are intended to be 
> compatible with fooc.
> In this case, even though it wouldn't be testable in cauldron, it could be tested in 
> backports-testing, and I think it could be a good idea to allow it.
>
> Even if fooc compatibility wouldn't be available for the next Mageia release, a user 
> could avoid updating for a release in order to keep using fooa.
> However, if there were no intention to make fooa compatible with fooc, maybe it should 
> be denied.

The example is bogus. If we have fooa in the distro and we upload fooc
that break it, then we have to fix the breakage as a priority. Usually,
that would be having foob and fooc as parallel installablable.

Anyway, the question is "how often does it" happens ? Because "it may
happen" is not a justification" if in practice, it never happen. And not
having a backport is not the end of the world so unless the problem is
quite frequent ( and so far, this one is far from being frequent ,
especially since it is based on a wrong supposition in the first part ),
I do not think this would be blocking.

> >> I like the idea of tagging backports in the package name, as well as in the package database.
> >
> > We cannot tag in the packages database. Yum do it with a separate sqlite
> > file, afaik.
> 
> I would like to see the source repository info available for every installed package.
> Maybe even stored somewhere in the .rpm file, also.
> Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add 
> new fields to the packages database ?
> (Although a parallel sqlite file would work.)

Compatibility would be indeed a concern. But if we move packages between
repository without rebuilding for QA reasons, this would also be
meaningless.
-- 
Michael Scherer



More information about the Mageia-dev mailing list