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

Re: Thoughts about tdebs

On Wed, 3 Dec 2008 16:32:17 +0100
Raphael Hertzog <hertzog@debian.org> wrote:

(I'm subscribed, no need to CC me)

> Anyway, having translation outside of the original package also
> represent a cost: 
> - manually installing a software requires download of 2 packages with
> the risk of badly mixing them
> - in term of preparation for the packager, he has to say what's part
> of the tdeb and what's not
> - in term of administration for the repository manager

True, but the Debian repository manager (ftp-master) is already happy
with the benefits of having translations completely outside the
original package. (Yes, ftp-master recognises the TDebs are a lot of
work and I got quite a few complaints from Joerg and Mark about how
much work was involved but still, after all that, TDebs are still
worthwhile for ftp-master.)

With regard to NEW, I'm sure we can arrange that during Squeeze+1,
uploads that merely add a TDeb have a fast-track through NEW -
as long as that this track is clearly identified and not abused. Plenty
of time to arrange this.

In terms of the packager, dh_gentdeb includes sufficient support for
95% of all packages using gettext to not have to care about what goes
into the tdeb, it is done automatically. This has been done
specifically to remove the need to modify the source package. See

The other support can be developed during Squeeze. The intention is
that migrating any package to TDeb support is mostly trivial:

(Just noticed that there is a typo there, the first two list items need
to be collapsed into one.)

Manually installing is not the way it will work. Think about debconf
templates - the translations need to exist before the package is
configured, therefore tdeb support implicitly means that apt will need
to be taught to get the TDeb alongside the package so that
apt-extracttemplates (from debconf) can locate the templates file and
use it with the maintainer scripts that are retained in the original
package. That is a relatively simple change - the TDeb is already
listed in debian/control and apt just needs to understand that
Package-Type: tdeb means "get this TDeb alongside anything else from
this source package". Whether untranslated debconf questions are
retained in the original package is a matter to be decided (for dpkg -i
support). "Badly mixing them?" - that is a matter for apt to reconcile
and dependencies to resolve. I don't see how the current spec would
allow for packages to be badly mixed but there is plenty of time to
find the corner cases as TDebs themselves will not arrive in the
archive until after the release of Squeeze. Quite a lot of work was
done on how the packages would combine during Extremadura. I don't
foresee any problems that the existing support cannot resolve.

(Is that not in the spec? If it isn't, I'll need to add something on

If that is unclear, please tell me what might need to be added for

> So while I agree that it would be good to resolve the problem of the
> translators, I don't think that it should be done at all costs. 

ftp-master agrees, as do I. However, TDebs are still desirable, as
outlined in the spec.

> In
> particular when the Emdebian-specific size-problem gets less and less
> real over the years (for my own semi-embedded projects, I have been
> forced to buy larger and larger DOM over the years as the smaller
> capacity are simply not produced any more).

I come across this sentiment a lot but it just isn't true. The NSLU2
has 6.4Mb available for the operating system so that it can finally
have the ability to change the external hard drive without rebooting
and also being able to use external storage that has not had to be
(extensively) reconfigured to support the OS. There are always
situations where the size of the installed OS is critical - hence
Emdebian Crush. Other devices out there do exist and there are
developers on the embedded mailing lists who are crying out for Debian
to support their machines - machines with generally between 10Mb and
64Mb available storage and *no* way of extending that storage without
completely redesigning the board. Debian is not the universal OS until
it can be adapted to such systems. Current Debian packaging insists
that the hardware be expanded to meet the requirements of the software
which, to me, is a Microsoft approach. I cannot meet the demands of
these users and developers currently because of the Lenny freeze -
TDebs are a small but vital part of this solution.

For intermediate installations, Emdebian Grip is more suitable -
anything with more than about 250Mb total storage. What you might call
semi-embedded, again using TDebs as the key instrument to reduce the
installation size and download size without losing translations.


> Whatever experiment you might have done within Emdebian, I will not
> trust any design decision that lacks a (serious) rationale and
> explanations of why the alternatives are not viable.

I can understand that, but I offer a challenge in response - I will not
be charitable to changes in design that lack the testing and
documentation even currently available for TDebs. Ideas are fine but
this is already a working implementation with a long history - and
existing approval from various teams in Debian who would need to be
considered in any design changes. Show me some code that works to meet
all the criteria required for TDebs and I'll consider it more
carefully. Show me code that meets with the requirements of
ftp-master and i18n and I'll be more interested. What's good for one is
good for the other.


> (That said, it's only my opinion and I'm not the one that maintains
> the C part of dpkg)

There will need to be minor changes in dpkg-dev too - dpkg-gencontrol.pl
only needs a minor tweak 
and  http://people.debian.org/~codehelp/tdeb/ch4.html)

Other changes are needed in devscripts and a few other packages.

The biggest changes are in the archive, hence ftp-master was approached
and the design altered substantially in discussion with ftp-master and
i18n teams during DebConf8 - this much was inevitable as all parties
accept that Emdebian TDebs cannot be implemented in Debian without
changes to the numbers of packages generated. Those changes are now in
place. The changes for dpkg, by comparison, are small. In many ways,
the scope of the changes within dpkg are dwarfed by the scale of
changes required in the archive and elsewhere and those changes, as
I said above, are already agreed with the relevant teams.


Neil Williams

Attachment: pgpldsQgHzyXe.pgp
Description: PGP signature

Reply to: