[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why doesn't dpkg link against gettext on Debian?


[ CCing you as I'm not sure if you are subscribed. ]

On Fri, 2009-07-24 at 18:35:14 +0200, Sjors Gielen wrote:
> The problem I'm facing is this. Our version of dpkg requires gettext.
> Currently, the package builds gettext along with itself, so it can be
> "built from scratch", I'm trying to change that to let it build against
> the gettext already in Fink, and have a dpkg-bootstrap package that
> builds with --without-nls. The version of dpkg we package is 1.10.21.

That version is pretty ancient, I'd recommend switching to something
newer, at least what's currently in the Debian stable release
(dpkg 1.14.25).

> Someone in the communities recommended me that it would be easier to
> implement if I could see how the Debian project fixes this bootstrapping
> problem. When I took a look, I saw gettext is barely mentioned in the
> control and rules files for sid's dpkg... No build-depends on the tools,
> no depends on the runtime. On my Ubuntu installation, which I guess
> should be most similar to Debian in this aspect, ldd tells me dpkg does
> not link against gettext dynamically, too.

> So I have two groups of questions:
> 1) Why can't I find any trace of gettext in dpkg's rules files? Has
> anything changed regarding this since 1.10.21? Etc.

I'd have to check for the 1.10.21 version, but for the current one,
there's three ways in which dpkg uses gettext (the “framework”):

  a) to do the runtime translation, which is provided by libintl, and
     on GNU systems that's embedded into glibc, so no external
     libraries get linked. On non GNU systems you need to have libintl
     on the system, which in your case could be a static library, so
     it does not need proper packaging.

  b) to check and build the translation catalogs (.po → .mo), most of
     those tools have a “msg” prefix in their command names.

  c) to be used by po4a to transform .po files into translated man pages.

> 2) How do you solve the problem of being able to build dpkg from
> scratch?

We don't do that. The only case where this usually happens in Debian
is when boostrapping a new port (read architecture).

> I think I read somewhere you now and then do a complete rebuild
> of the archive before a release.

The packages get rebuilt from time to time, not only before the
release, but only to make sure they are rebuildable, and the resulting
packages get always discarded.

> Where does that start? Do you start with a dpkg binary anyway? If you
> need to bootstrap Debian without any binaries but with a working
> compiler etc, is that possible, and how did you design your bootstrap
> process, knowing dpkg requires some dependencies to be already available?

The normal process when bootstrapping a new Debian port is to create
packages for a cross-toolchain, then you need to get all Essential and
Build-Essential cross-built as packages. Once you have all needed packages
to run debootstrap, building the rest is a matter of manually breaking
cyclic (Build-)Depends for the packages you are building.


Reply to: