On Thu, Apr 8, 2010 at 11:24 AM, Gaetan Nadon <[email protected]> wrote: > On Thu, 2010-04-08 at 10:17 -0700, Keith Packard wrote: > > On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson <[email protected]> > wrote: >> On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard <[email protected]> wrote: >> > On Thu, 08 Apr 2010 02:33:22 -0500, "Yaakov (Cygwin/X)" >> > <[email protected]> wrote: >> > >> >> 6) Please tell me you're not planning on releasing this package with >> >> the >> >> name "proto". :-) >> > >> > Oh. Yeah, probably not the best name. 'xproto'? 'xprotocol'? >> >> Well, considering we already have 'xproto' as one of the individual >> modules, it might make sense to go with 'xorg-proto'. That would be >> nicely synced with 'xorg-server'. > > Eric came up with an obvious solution here. We simply take over the > existing 'xproto' package and start with that existing version > number. It's not tied to any protocol visible number at all. > > I'll plan on bumping that to '7.1.0'. Seem reasonable? > > Then we switch the X server to depending only on that package with that > version number. We can still install the other .pc files for backwards > compatibility, but future changes would want to use only the xproto > version number. > > I like that. I am not sure, but are the old *.pc realy needed? It adds a
You'd have to change all the libraries and apps that depend on them. That's fine for xorg packages, but it's a little tougher to know about libraries out in the wild. At the very least, it would require that you reinstall all your xorg libraries with references to the individual package names removed so that pkg-config calls would resolve correctly. That seems excessive. > little bit to existing complexity: > > 1. individual protos can be installed using different $prefixes, so we have > identical pc filename in two locations That's no different than if you have your development package in $HOME and the system package installed. As long as you have PKG_CONFIG_PATH set appropriately, you should be fine. > 2. having dri2proto.pc, for example, would suggest $prefix/proto/dri2proto > is installed but it may or may not be. I think you wouldn't install dri2proto.pc if you weren't installing the associated headers. It's one AM_CONDITIONAL in the build. > 3. installing a downlevel dri2proto using same prefix would overwrite the pc > file installed by xserver-proto I'm not sure why you'd want to install an older, modular dri2proto when you have a more up to date copy in the monolithic proto package. I don't think the modular repos will be developed further after the merging. -- Dan _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
