[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