Re: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 12:37:41PM -0200, Henrique de Moraes Holschuh wrote:
> That said, it is sort of on-topic anyway. Can pkg-config be told which arch
> to build to? If it doesn't, it is high time to fix this, and it would fix
> the problem of getting .pc files to be installed to the right place, too.
Not yet. The simplest workaround is to create a wrapper around
pkg-config that sets PKG_CONFIG_LIBDIR based on the selected
architecture. Later we should add a "--arch" to pkg-config.
> Who cares if that means the pkg-config binary we ship will have to be a
> great deal more intelligent than the pkg-config other distros need? It
> would still work, and it wouldn't break cross-distro compatibility, either.
I think as long as the installed .pc files are backward-compatible it is
OK to introduce new features in Debian first and try to push the changes
upstream later.
> Unless packages ship the pkg-config binary itself. Even then, the Debian
> mode could be dependent on dpkg-architecture existing or somesuch, so people
> could still use Debian as upstream developers without hassle.
I do not think pkg-config should call dpkg-architecture. Instead I think
of something like this:
- the user decides the architecture (if we are building a Debian
package, then by calling dpkg-architecture)
- the selected architecture is passed to the build system (--host=
argument to 'configure', parameter to 'make' etc.)
- the build system passes down the information to pkg-config
This way there is a single point where the user can decide the
architecture (note that not all users are building Debian packages, and
not all users want to build for the default architecture, so
dpkg-architecture should not be mandatory).
> Debian utilities should ask dpkg-architecture about the running arch,
> probably (unless we export all the dpkg-architecture data to the environment
> and make that non-optional).
For Debian utilities, this is reasonable.
> Debian builds would then have to do whatever is needed to get the tools they
> use (autoconf, pkgconfig, etc) to build for the right arch. And the tools
> must be enhanced to allow the Debian build scripts to force which arch they
> are working for, if they don't have such features yet (autoconf does, and it
> actually works since 2.52 or thereabouts).
Yep. Multiarch is not common yet so there will definitely bugs and
missing features in various tools, but that cannot be helped.
> THAT said, package maintainers better know exactly how to make sure no
> feature autodetection by autoconf will get them with their pants down.
> It should only happen because they wanted it to, not because they lacked
> build-deps or build-conflicts. But THIS is a topic for another thread.
Don't forget that threre are regular users building their own stuff
under their home directories. Autodetection is really handy to make use
whatever is installed on the current system and not to worry about
optional components having missing dependencies.
I think many of the past & present problems with autotools (like the
-rpath issue, or too much dependencies in .la files) come from the fact
that autotools were created with these users in mind and little thought
was given for distribution-makers.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Reply to: