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

Re: Re: DEP-4: The TDeb specification.




On Fri, 03 Apr 2009 04:21:59 -0400
Filipus Klutiero <chealer@gmail.com> wrote:

> That would be a nice improvement, but let me suggest another > implementation. To avoid introducing a second diff, why not updating the > regular diff (in the case of non-native packages) but indicating that > the package shouldn't be entirely rebuilt when uploading? This seems > simpler.

That breaks the existing source package in Debian - the .dsc referring
to that .diff.gz has been signed by the maintainer and any changes will
break that signature.
Right - unless the .dsc is also updated. And if there is to be a tdiff, I don't see why .dsc-s wouldn't include the tdiff's digest.
TDebs are not related to source changes and
should not affect the existing source package. A TDeb upload needs to
sit alongside the existing files in the archive, not replace files
uploaded by the maintainer. This allows TDeb uploads during a release
freeze - even very late in a release cycle (which is the very time
that many debconf translations get updated currently).
That's the question. I don't see why adding a new diff would ease testing transition compared to updating the existing diff - given that the "traditional"/current binary packages aren't rebuilt when uploading translation updates.
> > > What is the purpose of creating a new binary package format for this (as > > > opposed to reusing, say, the deb format)?
> >
> > To support easier management of the translations, including allowing
> > users to only install the translations that are needed for one
> > particular installation, instead of every user getting every
> > translation for every package they install, whether those translations
> > are even supported or not.

> There are two ways to achieve this. One is per-language packages, the > other is localization packages with multiple languages but using > something like dpkg class support. Currently, the only way supported is > language packages, but introducing a new package format will not > necessarily allow the second way. Implementing this would take about the > same amout of work as implementing something like dpkg class support for > the deb file format.

? It's already implemented via a patch devised by Thomas Viehmann.
Great. Then it should be little work to implement the same for .deb.

[...]
> > TDebs are based on the .deb format, it is only a small change in the
> > organisation of the data.tar.gz but it simplifies various stages of
> > handling the resulting packages in the repository, in upload rules and
> > in other support tools.

> Well, without details, I can't approve wholeheartedly, but if this isn't > reinventing the wheel for no reason, the specification looks fine.

The DEP does describe the organisation of the data.tar.gz:
http://dep.debian.net/deps/dep4/#index5h2

Which details are missing from the DEP?
The data.tar.gz is correctly described, yes. The details I was referring to are the simplifications of "various stages of handling the resulting packages in the repository, in upload rules and in other support tools" you were talking about. These details don't need to be part of the specification, but could be somewhere in the DEP or in its presentation.
If you're actually asking to see the code, the changes were also put
into http://git.debian.org/?p=users/codehelp/dpkg.git;a=summary
No, I'm not asking to see the code...

[...]


Reply to: