Re: Re: tdiff (DEP-4: The TDeb specification.)
On Tue, 07 Apr 2009 09:57:30 -0400 Filipus Klutiero chea...@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.) I'll try to. Neil Williams wrote: On Mon, 06 Apr 2009 01:13:19 -0400 Filipus Klutiero chea...@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. I don't understand. If you have a source package which contains the source for a set of binary packages A, and the source for a set of binary packages B. You can change B's source without affecting A's source. This allows an infinity of source packages for the same source of A. Changing the source package does not imply a change in A's source. 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? I'm not sure I understand your question. In the case of a native package, there is no diff, so you can't integrate the source changes for translation debs there. In the case of a non-native package, orig is upstream's business, so you can't integrate the source changes for translation debs there. Unless you introduce a new file avoiding that, you need to integrate changes to native packages in the source tarball, and to integrate changes to non-native packages in the diff. 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. Why? Just who/what is supposed to modify the existing .dsc anyway? The archive software? That's indeed one way to do it. [...] 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. I'm now aware that l10n NMUs caused such issues. It's possible they do, but that impression would have a tiny impact. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
tdiff (DEP-4: The TDeb specification.)
Neil Williams wrote: On Mon, 06 Apr 2009 01:13:19 -0400 Filipus Klutiero chea...@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. 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). 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. (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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: tdiff (DEP-4: The TDeb specification.)
On Tue, 07 Apr 2009 09:57:30 -0400 Filipus Klutiero chea...@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 chea...@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
