[Mageia-dev] new mgarepo version

Sat Jul 16 13:13:42 CEST 2011

Le samedi 16 juillet 2011 à 12:34 +0200, Samuel Verschelde a écrit :
+> Le samedi 16 juillet 2011 12:20:22, Michael Scherer a écrit :
+> 
+> > I am not keen on pushing our newer tool on update, since we plan to have
+> > our server using mageia, and so in the futur, if we push newer iurt,
+> > mgarepo, rpmlint, they may potentially disrupt build system. So by being
+> > clear and using backports, we would avoid such problem more easily.
+> 
+> Except if you plan to use those newer version on the build system, in which 
+> case sending to updates_testing to have them well tested then pushed to 
+> updates would avoid having to install backports on the BS ?
+
+We already have backports on the BS, and we will likely not be able to
+avoid it.  For example, transifex, while not being part of the BS per
+se, is backported from cooker/cauldron. And it is planned to upgrade it
+to next stable release, as asked by i18n team. There is no way that a
+new tx would be pushed as update, that's too disruptive.
+
+Moreover, I do not exclude the case that someone would deploy the same
+build system as us ( let's say a company that provides custom version of
+Mageia, a university that deploy custom build of software, whatever ),
+and would prefer to not follow our upgrade path.
+
+So I think the build system stuff should not have a exception for
+updates.
+
+Now, the problem arise also because mgarepo is used on both client side,
+and server side. 
+
+On client side, it could likely fall as "needed to follow API changes",
+at least for this version ( like would tx-client, or wesnoth ), even if
+the problem is also the lack of web interface ( as this would avoid
+requiring a new command line client ). 
+
+But on server side, the update reason doesn't apply.
+
+So having a separate binary ( and/or tarball, while on it ) for the
+server part, and make sure this one do not change much would be cleaner,
+IMHO.
+
+-- 
+Michael Scherer
+
+