Bero, Thank's for your comprehensive reply and explanation. I wonder if there is anything we can do to minimise the impact of this issue. I have found one of the more time consuming issues for the tyro packager who is updating packages or even trying to create new ones are the build dependencies. Speaking for myself this is one of the most frustating parts of package update/creation. In the example in this thread there was no way for me to know the name by which I should call the pkgconfig file for for librsvg. I tried the obvious which failed so ultimately having realised that it was possible that the problem I was experiencing was related to a naming issue I had to install the package and then check the name of the installed *.pc file in order to determine the name I needed to use in the rpm spec file. I checked the specfile for librsvg but the %files entry simply showed %libdir/pkdconfig/* (or similar) which was no help at all and seemed to reflect a similar uncertainty of name by the original package. It seems to me that much time and effort could be saved by exerting a litlle discipline in this area. Specific naming of the *.pc pkgconfig datafile within the files section of the specfile would go a long way toward easing the pain of this unstandardised system. This is simple work but time consuming perhaps we could make this a task that people other than devs could help with. It should not be too difficult to create a script which would identifiy those specfiles that do not have proper naming then perhaps those that who wish to help could follow some simple instructions as to how to determine the proper name and insert it in the spec file. Once this work was completed it would be possible to create a cross-reference list to further ease the problem and maybe even incorporate this data into repository meta-data to allow it to be addressed by an abf or rpm utility, Is this worth considering for the new cooker? Best, Colin
On Friday, 26 August 2016 19:27:23 BST Bernhard Rosenkraenzer wrote: > On 2016-08-26 18:30, Colin Close wrote: > > Hi > > Recently I came across an issue with pkgconfig file naming and I would > > appreciate some advice. > > I recently added a BuildRequires pkgconfig(librsvg) line to a spec > > file I am working on. When I ran the build the librsvg package was not > > found. > > Further investigation showed that the package config file was named > > librsvg-2.0.pc note the appended version number. Is this correct? > > Yes. > > > The the major versions is contained within the *.pc file so it would > > seem that adding the major version to the name of the pc seems like > > overkill. > > Is there a convention for naming this type of file? > > There's multiple convention and every library follows a different one - > that's why there's not that much consistency. > > Some people think that as soon as a new version is out, the old version > should be deprecated anyway, so there's no point in having development > files for 2 different versions floating around on the same system. > That's why e.g. pkgconfig(libdrm) will always give you the latest and > greatest version of libdrm. > > Others think that something that has been released think it should be > supported forever and then some - so when librsvg 2.0 was released a > decade or so ago, it became pkgconfig(librsvg-2.0) while > pkgconfig(librsvg) would still give you librsvg 1.x if that was > installed/available. > > There's also inconsistencies about whether or not there's a "lib" prefix > (e.g. it's "libdrm" but "xcb" (not libxcb)). > > It's a mess, but we can't fix it on our side because everyone's build > scripts, Makefiles etc. are written to match the behavior of the > libraries they're looking for -- if we made them all follow the same > conventions, build scripts etc. written on another distribution or OS > simply wouldn't work anymore. > > pkgconfig is a mess in more ways than just this - but we don't get to > fix it unless we also rewrite everyone's build system. Fortunately at > least the KDE side of the world is moving more and more towards cmake > (but then again, even some cmake modules to check for stuff use > pkgconfig internally). > > ttyl > bero > _______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/mailman/listinfo/om-cooker_ml.openmandriva.org
