On Tue, Apr 10, 2012 at 11:40:32AM +0200, Christophe Fergeau wrote: > On Tue, Apr 10, 2012 at 11:28:34AM +0200, Marc-André Lureau wrote: > > On Tue, Apr 10, 2012 at 11:09 AM, Christophe Fergeau > > <[email protected]> wrote: > > > For what it's worth, one scenario where it's easier to go wrong than > > > before > > > is when distro patches have to be added to the protocol headers (for > > > example enum values which are used in messages sent over the wire). This > > > happens when distros decide to backport useful features. Before, > > > all that was needed was patching one place (spice-protocol), now the > > > header > > > needs to be patches N times, and it's not even a straight cherry-pick from > > > git, so I can imagine things going wrong there. > > > > If the project you build includes the protocol feature you wanted, > > then the result is correct. Before that, you had to recompile all the > > projects depending on spice-protocol, to make you sure didn't break > > any. > > For protocol additions, you didn't really need to rebuild projects not > using what was added. > The case I have in mind is for example someone backporting support for > controller message B in spice-xpi, and someone else backporting support for > controller message A to spice-gtk, and one of the 2 not paying attention > there are 2 different new messages. I agree this is a bit of a corner case, > but imo this is a drawback compared to how it used to work.... >
So the golden rule should be to not backport spice-protocol but use a version from upstream, not neccessarily the latest. Backporters beware. > Christophe > _______________________________________________ > Spice-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
