Thinking about this a bit more, and the strategy we can take going to ARC. I think we should put together a FastTrack where we highlight that these modules are non officially a part of the GNOME stack and we don't want people to use them, but we intend to install these modules to the normal locations where they are found in other distros.
We would obviously want to declare these interfaces as "Consolidation Private", and to communicate this to the end-user we would need to include section 3 manpages for each library where the library interfaces are marked as such. The FastTrack should also specify what the community future plans are. That these interfaces will be replaced with new interfaces. ARC may go along with this if we can make a reasonable argument that that it is unlikely that end users would want to use these interfaces. Though in the past, they have required that we do the sorts of things that I've been recommending (e.g. aspell). If so, we'll have to decide if the functionality that these new modules gives JDS is worth the extra effort. Brian Brian Cameron wrote: > > Jedy/Laca/Others: > > I do agree that what I am proposing makes life more complicated for > us now, but doing this sort of "extra" work would make the ARC > process easier. > > If the general concensus is that we want to ship headers and .pc files > for modules that we know are temporary and will go away, then I think > this will likely be controversial at ARC-time. > > Therefore I don't think this is appropriate to include in the 2.18 > umbrella case. The umbrella case is really intended for changes that > we know to be non-controversial. I recommend that these changes be > ARC'ed separately. Also, keep in mind that ARC may tell us that we > can't ship this unless we do this sort of work anyway. > >> I just checked evolutoin & gnome-applet, they both use .pc file to >> identify libnotify. If we do not ship .pc file, we have to modify very >> every module using libnotify and point out where libnotify is installed. >> Is this really a good idea? > > Just because we don't ship a pc file doesn't mean we couldn't use it > for our own internal builds. > > Brian
