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

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



Neil Williams wrote:
On Fri, 03 Apr 2009 16:45:46 -0400
Filipus Klutiero <chealer@gmail.com> wrote:

[...] <http://www.emdebian.org/media/debian-media/>

> > > 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.

There will be a complementary dsc using the +t1 version suffix.
That can work, though I don't see what you were trying to say.
[...]

> > > > > 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.

Package management tools need a way to tell a .deb from a .tdeb - the
two need to be handled differently by tools like dak, britney, apt,
dpkg, reprepro, deb-gview and others.
Do you mean that package management tools need a way to tell a traditional/current .deb from a package containing what the DEP proposes to put in a .tdeb? If you're only talking about the tdeb format per se, I don't understand your reasoning.


Reply to: