----- Original Message ----- > Hi, > > >> Maybe revisit upstream spice packaging? spice internal usage of > >> spice-protocol is handled via submodules now. Are there external > >> users, other than qemu? Does it make sense to keep the > >> spice-server / spice-protocol split in the first place? Or should > >> spice-server just provide the protocol headers too? > > > > spice-server is a much larger project then spice-protocol. The > > agents > > and the drivers don't need any bits in spice-server. > > I didn't meant to kill the spice-protocol git repo, just the way it > is > distributed. > > Remove any makefiles & stuff from spice-protocol, so it is really > just > the headers. Any spice-internal users get it as submodule like they > do > today. spice-server gets updated to also install the spice-protocol > header files from the submodule. > > Kills the whole protocol header version dance for the external users > (the submodule usage already does it for the internal ones). When > you've installed spice-server-devel you automatically also have > recent > enougth spice protocol headers installed. >
Yes, we could do it, I'm not sure it's worth the trouble. The only benefit is that it removes one more pkg-config check. But it means that anyone who wants to develop a new client has to install spice-server to get the client headers. Right now the protocol has other problems - it doesn't contain the complete protocol specification, spice.proto, that is actually in spice-common. And it's wrongly named - it contains the agent protocol and the device "protocol" as well. > > Sure, we can > > unify them - it would make it easier for qemu and Xspice (the only > > other external user). > > So both external users need the spice server too. So I think it > makes > sense to have spice-server ship the protocol headers. > > cheers, > Gerd > > >
