? wrote: > Roland Mainz wrote: >> Magne M?hre wrote: ...[snip]... >>> 4.5. Interfaces: >>> Provided interfaces: >>> package: >>> SUNWproj uncommitted >>> >>> include files: >>> /usr/include/nad_list.h uncommitted >>> /usr/include/org_proj4_Projections.h uncommitted >>> /usr/include/proj_api.h uncommitted >>> /usr/include/projects.h uncommitted >> Is it possible to move this into a subdir like /usr/include/postgres/ or >> /usr/include/proj4/ ? I'm a bit worried that this stuff more or less >> sits in the global include namespace for all applications... for example >> /usr/include/project.h may be confused with /usr/include/projects.h >> which is a system header for the Solaris "projects" feature. > > proj is not a postgresql package. It is a generic support library > for GIS applications, and widely used in that business segment. > I have no objections to putting the include files in > /usr/include/proj4, if that is the recommended approach ?
When I designed Pluggable fwflash, I included delivery of a header file in usr/include/fwflash. I believe that this is the appropriate model to follow in general. >>> user binaries: >> Same question here: Is there a reason why this must be in /usr/bin/ and >> cannot sit in /usr/postgres/bin/, /usr/postgres/bin/ or /usr/proj4/bin/ >> ? If it should remain in /usr/bin/ - would it be usefull to add "proj4_" >> as prefix for all utilties (except "proj" itself) ? > > I'm opposed to adding a prefix as that would confuse users. A separate > directory (/usr/proj4/bin) is acceptable to me Confusion because it's not what users see on other platforms? I can understand that. I don't think placing these binaries in a separate hierarchy is necessarily a good idea - I get the impression that proj isn't a large entity such as the xpg4 and gnu deliveries, so I'd stick with usr/bin in this case. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
