On Tue, 07 Apr 2009 09:57:30 -0400 Filipus Klutiero <chealer@gmail.com> wrote: (Could you add a blank line between the quoted reply and your content? It makes the content easier for me to read. Thanks.) > Neil Williams wrote: > > On Mon, 06 Apr 2009 01:13:19 -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 also involves separate handling for native vs non-native packages. > > The DEP does not require that - the +t1.diff.gz is used for native and > > non-native. Any changes to the .diff.gz (or .tar.gz for native > > packages) uploaded by the maintainer would require a source rebuild in > > order to maintain the integrity of the archive - that is precisely what > > the DEP is trying to avoid. You can't have a source package in a state > > that says "this isn't the source we actually used to build the binary". > > The source to build the .deb needs to be unchanged. > > Yes, but the source package contains more than the source used to build > the "traditional" binary packages. It also contains (potentially) source > for translation debs. As long as the only source changed is the source > for the translation debs, the "traditional" binary packages don't need > to be rebuilt. But the source package would still be the wrong source for the binaries that exist. The archive needs to contain the unique source package for the binaries that exist, modifying the source without modifying the binaries is not an option for legal reasons, as I understand it. > > The changes made to > > generate the .tdeb need to sit alongside the existing source package > > and have absolutely no effect on anything related to the binary > > packages or the source package uploaded by the maintainer. > > Per what I wrote above, I don't see anything preventing the source > changes for translation debs to be integrated in the traditional diff > (again, in the case of non-native packages). Why treat the two differently? Whether the package is native or non-native makes no difference to how the TDeb is generated or handled. It has a bearing on which packages will be handled at which stage of the transition to TDebs but nothing beyond that. > > > > > > 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. > > > > That there should be no update to the .dsc because the existing source > > package must not be altered, therefore the second .dsc with the +t1 > > version suffix. In the case of a TDeb update during a release > > freeze, the .dsc signed by the maintainer is already part of testing so > > the TDeb upload to unstable must not change that .dsc. > > I don't see a problem preventing the traditional .dsc to be changed. > Changing the .dsc does not imply that the existing source package must > be altered. The .dsc could be updated in testing. If the .dsc is modified, the source package no longer matches the binaries that are in the archive that were built from the old .dsc. Just who/what is supposed to modify the existing .dsc anyway? The archive software? TDebs are not necessarily built from an unpacked source directory, they can be built by tools working just from the POT file and PO contributions. Yes, the +t0 TDeb, the one created by the maintainer, will have the normal source and the normal tools, there is nothing to say that +t1 would have the unpacked source available necessarily. Translators will often have the source in order to test the translation but the final +t1 TDeb will collate the contributions of several translators and several translation teams, via several sources. The +t1.dsc is likely to need to be signed but merging that with the existing .dsc could give the utterly misleading impression that the nominated l10n person doing the upload is somehow responsible for the binary packages that have not been touched but are affected by the change to the .dsc. This is another area where TDebs are quite different to normal .deb - there is nothing to say that dpkg-buildpackage has to be involved, none of the standard Debian build tools need exist other than dpkg itself (not even dpkg-dev, although that would be unusual). > > (Whether the > > +t1.dsc is retained is a different issue - I suspect that we only > > actually need to retain the +t1.diff.gz but as any .dsc is tiny, it > > isn't a big issue either way.) > > I think it should be retained; small issue, indeed. > > To sum up, I still don't see anything that imposes introducing a tdiff, > even to avoid rebuilding the traditional binary packages. But, I'm > starting to see tdiff is probably a good idea anyway for security reasons. I don't see how retaining the +t1.diff.gz but merging the +t1.dsc into the existing .dsc is logically consistent. I'm not too fussed about the +1.dsc other than as a vehicle for the upload itself and to have an appropriate .dsc describing the TDeb changes, but I don't see that modifying the existing .dsc is correct. The idea for +t1.diff.gz came from DebConf8, during the meeting with ftp-master, IIRC it was their solution to integrity problems within the archive, especially but not exclusively when TDebs were to be uploaded during a release freeze. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpLx6quAjVFW.pgp
Description: PGP signature