Bug#1007717: Native source package format with non-native version
Helmut Grohne writes ("Re: Bug#1007717: Native source package format with non-native version"):
> 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.
As you surmise, the only urgency I feel is due to these deprecation
efforts (some of which take other forms).
> 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.
It is a shame that these bugs were filed and a lot of maintainers
(including at least one of my sponsees) now find themselves in a
confusing position. Perhaps it would be worth sending an agreed
holding message to these bugs, and/or blocking them by this one.
> 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.
Yes, that is by and large my SNPS (solution neutral problem statement)
for the ideal situation.
But, note that "faithfully" implies not including a copy of the Debian
delta in the form of patches within the unpacked source tree (as "3.0
(quilt)" does), since those patches must then be kept up to date.
And, I want a format that offers the bandwidth and disk space
optimisation of not re-uploading large files when only small changes
are made. This is necessary for large packages. The various
with-diffs/with-patches formats achieve this, but compromise on other
aspects.
> > 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.
You are correct. But there is not currently any format that meets all
of my requirements.
In particular, 1.0-with-diff achieves the bandwdith/storage
optimisation, at the cost of representational capability.
Looked at this way "3.0 (quilt)" is mixed - it has some additional
representational capabilities, but reduced fidelity.
> 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.
Um. The conversions done by dgit exist to *keep the pollution up to
date*. And they are really quite inconvenient. dgit must make
commits on your branch, or maintain multiple branches. There is a
substantial amount of code there, dealing with a large variety of
different situations.
> 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.
In practice, the vast majority of packages are maintained in git on
salsa. The maintainers use those git repositories as the PFM.
The git repositories contain much information which is not in the
source packages (generated by gbp or dgit on maintainers' machines),
and, depending on the package, that information is sometimes critical.
IOW that ship has sailed.
My programme of properly supporting git in Debian is trying to sort
out this situation, by providing a discoverable, coherent, and
reliable git view of every package. Unfortunately that is blocked
due to unfounded "security concerns".
I note that "3.0 (quilt)" with single-debian-patch exists and is fully
supported. No-one appears to be trying to get rid of it.
> 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.
Mandating *more* use of patches-and-tarballs is a step backwards.
The .dsc source format (which I first invented in 1992 is now
obsolete). We must maintain it for compatibility for a very long
time, but almost everyone is already treating git as primary.
But our git setups are not official, not coherently discoverable or
useable.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Reply to: