Hi Ian, On Tue, Mar 15, 2022 at 04:29:17PM +0000, Ian Jackson wrote: > (Sorry for the resend, this should have gone to the BTS the first > time; have fixed a slip in the wording.)
Thank you for resubmitting your issue as a bug report. Beyond the content of your request, I have a meta-question. Do you see a particular urgency with the processing of your request? What is - in your opinion - a reasonable time for resolving this? Of course, if Lucas et al are to proceed with their deprecation work, urgency may arise in your view, but let us assume that we can ask them to pause their efforts for a while. Lucas, please pause further work on deprecating the 1.0 format in order to give time to settle the dispute at hand. This implies not sending further bugs about it. On the other hand, I think closing all of the existing ones would not do any good at this time either. > Please: I note that you request a number of partially independent matters that form disagreements with various people. The request is fairly entangled (as is the matter at hand). I'm also wondering whether your request may be over-specific. Can I ask you to step back a bit and help us figure out what you really want to achieve? Given your other messages on the matter, I suppose that you want to be able to use a source package format that can faithfully represent any valid source tree. In particular, a source tree with a Debian revision should be representable. You care less about being able to represent differences to a tarball in some cases as long as the changed tree as a whole is representable. This includes changes to permissions, symbolic links and binary files. Which source format is used is not important to you as long as it is able to meet these requirements. Do you consider the above representation of your view accurate? If not, please point out differences. > 3. Consequently, declare that the recent MBF on this topic ought not > to have been filed against packages where simply changing the > source format does not currently work. That would include at > least 1.0 native packages with Debian revisions. On a technical level, there is not much point in ruling that something should not have happened. It did happen. The strongest thing that would be possible here would be to rule that these bugs should be closed. > Part II - bless continued use of 1.0-with-diff, for now at least: > > 4. Declare that sometimes the use of 1.0-with-diff can be the best > tradeoff between different considerations. In particular, > because 1.0 is the only format which botH: > (a) Optimises bandwidth and storage by reusing the upstream > data when it hasn't changed. > (b) Avoids polluting the working tree (package source code) > with [patches], which cause trouble especially with > git-based workflows. I note that the 1.0-with-diff format does not meet my perception of your earlier requirement: Being able to represent any source tree. I also note that it is possible to choose a different conversion mechanism than dpkg-source -b between working tree and .dsc that does not incur your reported pollution. In particular, you do have experience in implementing such conversions as is evidenced in dgit and such conversions do exist. Your request also touches the question of the preferred form for modification. That used to be the .dsc, but for the way you use the archive, it merely is an export for a preferred form for modification that resides elsewhere. I do not think we have consensus for this view either. I also caution that whenever we perform a fundamental change, some things that used to work well, stop working well. Many improvements regress on other aspects that are deemed niche features. I think it is fair to say that use of 1.0 packaging formats is a niche at this point. Consistency has value, but it comes with a price of making some niche features impossible. We are discussing a trade-off between consistency and niche features here. Helmut
