Fink:Packaging:pkg-config - Revision history

Dmacks: old old

2017-03-26T21:18:29Z

old old

Dmacks: /* About pkg-config and .pc files */ alt

2017-03-26T21:16:29Z

About pkg-config and .pc files: alt

Dmacks: Reverted edit of RjoJ0v, changed back to last version by Nieder

2007-06-11T09:10:38Z

Reverted edit of RjoJ0v, changed back to last version by Nieder

New page

{{Fink_Header}}

This page explains our current best-guess about how to do dependencies on the pkgconfig package.

==About pkg-config and .pc files==
<code>%p/bin/pkg-config</code> is a tool that packages use to determine flags for compiling against other—usually library—packages. The headers component packages of library packages supply a .pc data file that pkg-config reads.

Some .pc files contain syntaxes that are only compatible with certain newer versions of pkg-config and either cause <code>./configure</code> errors or silently pass incorrect flags when used with older versions. Therefore we need a way to make sure that the proper version of the pkgconfig package is used. These requirements can change version-to-version in the library package and have nothing to do with the packages that use pkg-config. it's not reasonable to keep altering the <code>BuildDepends:pkgconfig</code> versioning in every package that uses the library.

However, there may be other programs that can read .pc files and that may supply an alternate (and compatible) <code>pkg-config</code> program. Therefore we don't want to over-do dependencies on pkgconfig, since that will lead to a mess if any of those other programs get packaged for fink. They would presumably <code>Conflicts/Replaces:pkconfig</code>, so any <code>Depends:pkgconfig</code> will block a smooth upgrade.

A .pc file is pretty useless without a program to process it and pkg-config is the standard tool other packages use. Therefore it makes sense to have packages with .pc have some sort of dependency on pkgconfig. This situation is similar to -dev packages that need other -dev packages, but where BDO prohibits a Depends. Ideally, packages with .pc that have specific pkgconfig versioning requirements would declare an [[Fink:Major New Feature Plans:InheritedBuildDepends|InheritedBuildDepends]] on it, since pkgconfig is used at build-time. However, we don't have that field. Should pkgconfig itself become BDO when we implement IBD?

==Suggested Best-Practices==
Our best solution for the present is to have any library (or other) package that has a .pc with specific version requirements for pkg-config to declare a versioned <code>Depends</code> on the "pkgconfig" package, and packages with .pc files that can be used with any pkg-config version to have no dependency on pkgconfig.

*.pc file in %p/share/pkgconfig instead of %p/lib/pkgconfig
:The share/ location was added to the default search path starting in fink's packaging of pkgconfig-0.20. Older versions of the package only looked in the lib/ location. A package that installs a .pc file in the share/ location should declare a <code>Depends</code> to require a pkgconfig version that looks there.
*<code>*.private</code> field in .pc file
:The <code>*.private</code> fields were implemented starting in pkgconfig-0.20. Older versions of the pkg-config program silently ignore these fields could therefore supply a deficient set of flags. A package containing a .pc file that has any <code>.private</code> fields needs to declare a <code>Depends</code> to mandate a pkgconfig version that supports them.

{{Fink_Header}}

[[Category: Fink|Packaging:pkg-config]]
[[Category: Fink Packaging|pkg-config]]

← Older revision		Revision as of 21:18, 26 March 2017
Line 16:		Line 16:

	==Suggested Best-Practices==		==Suggested Best-Practices==
		+	'''THIS SECTION IS OBSOLETE (or at least on hold). pkg-config has been beyond 0.20 for years and no currently supported tree has ever had a version older than that, so we do not need to set runtime dependencies to ensure what doesn't seem possible to be likely to be un-met anyway.'''
		+
	Our best solution for the present is to have any library (or other) package that has a .pc with specific version requirements for pkg-config to declare a versioned <code>Depends</code> on the "pkgconfig" package, and packages with .pc files that can be used with any pkg-config version to have no dependency on pkgconfig.		Our best solution for the present is to have any library (or other) package that has a .pc with specific version requirements for pkg-config to declare a versioned <code>Depends</code> on the "pkgconfig" package, and packages with .pc files that can be used with any pkg-config version to have no dependency on pkgconfig.

← Older revision		Revision as of 21:16, 26 March 2017
Line 11:		Line 11:

	A .pc file is pretty useless without a program to process it and pkg-config is the standard tool other packages use. Therefore it makes sense to have packages with .pc have some sort of dependency on pkgconfig. This situation is similar to -dev packages that need other -dev packages, but where BDO prohibits a Depends. Ideally, packages with .pc that have specific pkgconfig versioning requirements would declare an [[Fink:Major New Feature Plans:InheritedBuildDepends\|InheritedBuildDepends]] on it, since pkgconfig is used at build-time. However, we don't have that field. Should pkgconfig itself become BDO when we implement IBD?		A .pc file is pretty useless without a program to process it and pkg-config is the standard tool other packages use. Therefore it makes sense to have packages with .pc have some sort of dependency on pkgconfig. This situation is similar to -dev packages that need other -dev packages, but where BDO prohibits a Depends. Ideally, packages with .pc that have specific pkgconfig versioning requirements would declare an [[Fink:Major New Feature Plans:InheritedBuildDepends\|InheritedBuildDepends]] on it, since pkgconfig is used at build-time. However, we don't have that field. Should pkgconfig itself become BDO when we implement IBD?
		+
		+	== Alternative implementations ==
		+	<code>pykg-config</code> is a pure-python implementation of pkg-config. Its upstream development seems to have stopped, so it might not have all the latest features of pkgconfig itself. However, <code>pkgconfig</code> has build-time and runtime dependencies on glib2. Two main reasons one might want pkyg-config is to avoid the glib2 dependency tree and to avoid circular dependencies within the glib2 dependency tree itself.

	==Suggested Best-Practices==		==Suggested Best-Practices==