Re: Thoughts about tdebs
On Tue, 02 Dec 2008, Neil Williams wrote:
> > It is a very sizable special case, though, and growing thanks to the
> > tireless translation efforts within and beyond Debian. This is why the
> > consensus at the meeting seemed to be to get this right even if it
> > means having to implement some special casing.
>
> Raphael - I think you've missed some of the purpose behind TDebs and if
> that is a fault of the current draft TDeb spec, then I would value
> your comments on how to fix it.
I hear the size problem that Emdebian is facing but Tdeb is not the right
solution for this either IMO. We should rather aim at having some
DEB_BUILD_OPTIONS or something similar to instruct the build process
to create the minimalist package that you need instead of dropping the
translation entirely from the original .deb.
You can always continue to use Tdebs to distribute the translation that
you need while installing the minimalistic .deb.
> If the idea becomes separated from translations, automated creation of
> TDebs by translation review teams would be compromised, difficulties in
> re-assembling the source to ensure that subsequent uploads retain the
> intervening translation updates become even more complex and the drive
> to deliver TDebs starts to wane. (Personally, I am also not at all
> convinced that ftp-master would consider partial debs as a viable
> option.)
I'm sorry but the technical choice has little to do with the ability of
translation teams to create .tdeb.
> A key point of agreement with ftp-master is that the TDeb can be
> updated entirely separately from the rest of the package - this is
> absolutely essential to all concerned. If the idea gets diluted to
> include security updates (which almost inevitably change the compiled
> binaries of any compiled package involved in a security bug) then this
> update method becomes impossible and we start talking about binary
> patches or mass-replacement of binaries by partial debs. I find that
> idea more than a little insane. ;-) It would be a sizeable regression
> even from where we are now with binNMUs and source NMUs. This is about
> removing the code churn from i18n updates pre-release, it is about
> preventing translation updates during a release freeze from
> ever rebuilding any binaries.
You're making assumptions that you shouldn't do at this point. Whatever
you manage to do with .tdeb can be done with partial .deb…
I propose an idea so that people can think about it and you're trying to
argue that it can't work and that it's insane and that we shouldn't even
think about it.
> However, updates to existing packages is only half the story - the
> drive for TDebs has come from Emdebian. Emdebian must have TDebs in
> order to meet any of the objectives for Emdebian itself. Partial debs
> are not a solution, embedded systems need intelligently handled
> translations and lots of smaller packages. The Emdebian solution
> for TDebs cannot work within Debian unmodified, everyone accepts this,
> but the Emdebian requirements do need to be achievable directly from the
> Debian implementation.
And can you explain why "Partial debs are not a solution" ? I see no
justification in your paragraph. Partial .deb could be used to add
translations to any package in theory.
> The current specification supports this - partially via the premise
> that TDeb updates only contain changes to translations and partially
> because the individual localisations can be easily split out to create
> the extra packages for Emdebian (as described on the Emdebian website
> at the link above).
You could do the same with the set of partial deb dedicated to
localization. Don't mix technical choices with policy choices.
> There are use-cases for such things but I am not the one to take on
> that task.
Well, when someone ask me to modify dpkg, I try to look at the bigger
picture because that's what makes sense.
I know that you have a lot of energy and enthusiasim for Emdebian and
related projects but please do not use that energy to reject outright any
suggestion that you don't like at first sight.
> Actually, from my perspective, your idea is far from simple and seems
> to be a lot more complex than anything so far agreed with ftp-master.
>From a dpkg point of view, I find my idea simpler. :) We all have biases
but we should try to step back and see further in general.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: