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. http://people.debian.org/~codehelp/tdeb/ch9.html#s9.1 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 http://people.debian.org/~codehelp/tdeb/ch6.html http://git.debian.org/?p=users/codehelp/debhelper.git;a=summary The other support can be developed during Squeeze. The intention is that migrating any package to TDeb support is mostly trivial: http://people.debian.org/~codehelp/tdeb/ch6.html#s6.3 (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 that.) http://people.debian.org/~codehelp/tdeb/ch7.html#s7.2 If that is unclear, please tell me what might need to be added for clarification. > 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. http://www.emdebian.org/emdebian/flavours.html > 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. http://www.emdebian.org/emdebian/langupdate.html http://www.emdebian.org/locale/search.php > (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 (see http://git.debian.org/?p=users/codehelp/dpkg.git;a=commit;h=f7e88a887f4a7e3a9d6b8cbfbfef561a3533a5c6 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpldsQgHzyXe.pgp
Description: PGP signature