Brian Cameron wrote: > > Mark: > >> If these files are to become first class citizens, just like a .h >> file or a .so, > > Since the pkg-config interfaces are already Committed, I'd think they > are already first-class citizens. I stand corrected then. > >> should we at least have something describing them, and how to use them? > > Do you find the pkg-config manpage incomplete? Nope, just not available to me. I also missed it the first time I looked for it (I can't exactly grep on sac.eng). I've just found that there's a spreadsheet of all cases available in the root that lists at least the case name. I'm filing in the blanks now, and realizing the history gap I had was that pkg-config has been in use for a while, especially by the desktop team (and presumably others). ".pc" files are as common as dandelions, and I'm just late to the party. > >> Just like with jar files, it seems a bit short sited to just let >> these artifacts be delivered without any attempt to define both >> production and consumption in view of stability. > > The external FOSS community seems to be managing them pretty well. I > have never heard of any problems, nor am I aware of any stability issues > the Desktop team has encountered in the many years we have delivered > the bulk of the .pc files you find on Solaris. Do you have an example > of a specific issue that you are concerned about? Nope, just noted an admonishment somewhere on the pkg-config site about how the file format had changed. I didn't note when, and I certainly have no idea about how much of an impact that might have been. > >> In this particular case we've pretty much marked the whole shooting >> match as volatile, so it's probably moot, I admit. > > Really .pc files should probably be listed as Uncommitted. Listing it > as Volatile doesn't really make sense, and doesn't reflect how they are > used. The interfaces of a .pc file, the filename used for a given > module, and the file location are not Volatile. > >> I don't want to get into a "not this case" position, so I'll only >> suggest to the team to slap a version number in the .pc file name >> (now and in the future) and conclude my comments on this case. > > This would be inappropriate. Other modules refer to the .pc files by > filename. So, changing the filename would break any module which > depends on this interface. > > If this library is intended to be parallel-installable, then a version > number may be appropriate to include in the filename. However, this > change should be done at the source upstream, and not a change made by > a specific distro. Changing the filename breaks how it works. As I > say above, if you want to install multiple versions of the same .pc > file, you do this by installing them to separate directories, not by > changing the filename. Fine, I see -- especially with Danek D. and Alan C. also chiming in elsewhere on this thread. I'll withdraw the suggestion and my comments as this is clearly autotool+pkg-configuration fu I do not possess. Heck, after a recent trip down memory lane a few weeks ago with a small C project, I should probably just keep my nose out of anything that doesn't require dynamic typing or a virtual machine anyway.
I'm still struggling with the knowledge that the upstream plans to migrate to a new major version any moment now, and we /seem/ to be acting here as if this is some sort of evolving, non-standard interface and we've no plans of multi-version co-existence (volatile vs. uncommitted). But the team's worked it out and I can live with that. At least as far as the .pc file versioning is concerned -- that's the upstream's problem anyway. Moving along, I've done my damage.
