[Mageia-dev] new mgarepo version

[Michael Scherer]

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