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

Bug#1007717: Native source package format with non-native version

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

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.


Reply to: