Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1007717: Native source package format with non-native version
106 views
Skip to first unread message
Ian Jackson
Mar 15, 2022, 12:40:03 PM3/15/22
to
Package: tech-ctte
(Sorry for the resend, this should have gone to the BTS the first
time; have fixed a slip in the wording.)
Please:
Part I - belss continued use of 1.0 native format, for now at least:
1. Declare explicitly that there is nothing wrong with a package with
a native format, but a non-native version number.
2. Request that the dpkg maintainer relax the restriction which
prevents the use of 3.0 native with Debian revision.
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.
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.
5. Consequently, declare that the recent MBF on this topic ought not
to have been filed against 1.0 with diff packages, at least
without some further filter.
--
Ian Jackson <ijac...@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.
--
Ian Jackson <ijac...@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.
(Sorry for the resend, this should have gone to the BTS the first
time; have fixed a slip in the wording.)
Please:
Part I - belss continued use of 1.0 native format, for now at least:
1. Declare explicitly that there is nothing wrong with a package with
a native format, but a non-native version number.
2. Request that the dpkg maintainer relax the restriction which
prevents the use of 3.0 native with Debian revision.
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.
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.
5. Consequently, declare that the recent MBF on this topic ought not
to have been filed against 1.0 with diff packages, at least
without some further filter.
--
Ian Jackson <ijac...@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.
--
Ian Jackson <ijac...@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.
Sean Whitton
Mar 15, 2022, 1:00:03 PM3/15/22
to
Hello,
On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> Please:
>
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
>
> 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.
>
> 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.
>
> 5. Consequently, declare that the recent MBF on this topic ought not
> to have been filed against 1.0 with diff packages, at least
> without some further filter.
I think that you are asking us to use 6.1.1/6.1.2 for most of this, but
for I.3 are you asking for us to use 6.1.4 or 6.1.5? "Request" seems
more like 6.1.5 but I would like to check.
--
Sean Whitton
On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> Please:
>
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
>
> 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.
>
> 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.
>
> 5. Consequently, declare that the recent MBF on this topic ought not
> to have been filed against 1.0 with diff packages, at least
> without some further filter.
for I.3 are you asking for us to use 6.1.4 or 6.1.5? "Request" seems
more like 6.1.5 but I would like to check.
--
Sean Whitton
Sean Whitton
Mar 15, 2022, 1:00:03 PM3/15/22
to
This mail from Ian last week is helpful (technical) background.
--
Sean Whitton
-------------------- Start of forwarded message --------------------
From: Ian Jackson <ijac...@chiark.greenend.org.uk>
Message-ID: <25128.55315....@chiark.greenend.org.uk>
Date: Wed, 9 Mar 2022 16:38:43 +0000
To: Sean Whitton <spwh...@spwhitton.name>
Cc: Russ Allbery <r...@debian.org>,
debian...@lists.debian.org
Subject: Re: proposed MBF: packages still using source format 1.0
Sean Whitton writes ("Re: proposed MBF: packages still using source format 1.0"):
> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
> > On 08/03/22 at 17:33 -0700, Sean Whitton wrote:
> >> Lucas, as I've had a lot to do with these git workflows and have
> >> probably done the most work documenting them, I can help with any
> >> specific follow-up questions you might have.
> >
> > Thanks!
> >
> > So the main question I think I have is:
> >
> > can we find a middleground where the git workflows don't require staying
> > with 1.0? Even if that means switching to 3.0 (quilt) using the
> > single-debian-patch approach?
>
> dgit-maint-merge(7) works with single-debian-patch and that's what I
> use. But it is not clear to me that there are any advantages at all to
> that over 3.0 (quilt) with single-debian-patch?
The situation here is complicated.
The tl;dr is that
* there are several situations where 1.0-native is the best answer,
* there are several situations where 1.0-with-diff is the best answer,
The root cause of both of these situations is that 3.0, sadly,
is not always better in every respect than 1.0.
1. Why is 1.0-without-diff not always worse than 3.0 (native) ?
1.0 native is sometimes better than 3.0 (native) because dpkg-source
refuses to build a 3.0 native package with a Debian revision in its
version number.
This prohibition exists solely because of a doctrinal objection to
native-format packages with Debian revisions. There is no technical
reason why this restriction could not be lifted. I sometimes upload
this way and I have never had anyone report problems[1] with it.
IMO there is nothing wrong with native format packages with Debian
revisions. They work just fine. For a small paockage, this is often
a good choice, because it avoids dealing with patches at all.
For anything but a small package, use of diffs is needed as a storage
and distribution optimisation.
2. Why is 1.0-with-diff not always worse than some 3.0 format ?
1.0-with-diff has the following advantage over 3.0 (quilt):
The extracted source tree does not contain a diff. The inclusion of
the diff *inside* the source tree (which happens with "3.0 (quilt)"
whether or not single-debian-patch is specified) causes all manner of
problems: it means that only certain states of the extracted tree are
valid.
With 3.0 and single-debian-patch, modifying ordinary files can
generate a tree which doesn't round-trip through dpkg-source --build
and dpkg-source --extract: dpkg-source --build needs to "commit" the
changes to the diff, amending the working tree.
In other words, the working tree contains output files. This causes
trouble if you want to represent the package in git. This is why dgit
has all this quilt-fixup stuff. With 1.0-with-diff, no quilt fixup is
needed.
3. Why is 1.0-native not just as good as 3.0 (native) ?
The only significant advantage of 3.0 (native) is that dpkg-source is
willing to create and extract 3.0 packages using newer compression
algorithms such as xz.
There were no good reason why the additional compression algorithms
were not supported in 1.0. ("3.0 (native)" does offer some minor
metadata format advantages, so its existence is not entirely
pointless.)
If the restriction against native format with Debian revision were
lifted, "3.0 (native)" would be as capable as 1.0-without-diff, and
slightly superior. So in that case, "3.0 (native)" should probably
replace all uses of 1.0-native.
4. What disadvantages does 1.0-with-diff suffor from, compared to "3.0
(quilt)" with single-debian-patch ?
The main disadvantage is that there are changes to the source tree
which are representable in "3.0 (quilt)" but which 1.0-with-diff does
not support. (The precise details and the history are too compiex to
go into.)
I haven't checked recently, but this used to be enforced both on
building and on extraction. So changing this is not so simple, since
we shouldn't start distributing packages in a new source format (or
variant) until the new extraction capability is very widely deployed.
But, ultimately, it would probably be a good idea. Whether the to
call resulting thing "1.0" or "3.0 (diff)" doesn't really seem very
important.
The important properties are that it should support at least every
change that current diff(1) can represent.
5. Why is native sometimes superior to any quilt or diff format
We rely on diff(1) to represent changes to source trees and patch(1)
to apply them. Not every change is representable by diff.
diff/patch does improve, of course. That is not an unalloyed benefit,
though, because it means that when diff/patch improve we can
accidentally generate source packages that earlier versions can't
extract - a compatibility hazard.
Changes not representable by diff is what Sean is talking about here:
> Ian has some cases where something that is representable in git is not
> representable using 3.0 (quilt) but is representable using 1.0. I don't
> have those cases to hand; Ian, could you summarise, please?
Currently, I think diff cannot represent changes to symlinks.
git can store symlinks and represent their targets, and changes to
their targets.
Ian.
[1] By "problems" I mean "some software did a wrong thing", not
"I am offended by your breach of my notions of propriety".
--
Ian Jackson <ijac...@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.
-------------------- End of forwarded message --------------------
--
Sean Whitton
-------------------- Start of forwarded message --------------------
From: Ian Jackson <ijac...@chiark.greenend.org.uk>
Message-ID: <25128.55315....@chiark.greenend.org.uk>
Date: Wed, 9 Mar 2022 16:38:43 +0000
To: Sean Whitton <spwh...@spwhitton.name>
Cc: Russ Allbery <r...@debian.org>,
debian...@lists.debian.org
Subject: Re: proposed MBF: packages still using source format 1.0
Sean Whitton writes ("Re: proposed MBF: packages still using source format 1.0"):
> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
> > On 08/03/22 at 17:33 -0700, Sean Whitton wrote:
> >> Lucas, as I've had a lot to do with these git workflows and have
> >> probably done the most work documenting them, I can help with any
> >> specific follow-up questions you might have.
> >
> > Thanks!
> >
> > So the main question I think I have is:
> >
> > can we find a middleground where the git workflows don't require staying
> > with 1.0? Even if that means switching to 3.0 (quilt) using the
> > single-debian-patch approach?
>
> dgit-maint-merge(7) works with single-debian-patch and that's what I
> use. But it is not clear to me that there are any advantages at all to
> that over 3.0 (quilt) with single-debian-patch?
The situation here is complicated.
The tl;dr is that
* there are several situations where 1.0-native is the best answer,
* there are several situations where 1.0-with-diff is the best answer,
The root cause of both of these situations is that 3.0, sadly,
is not always better in every respect than 1.0.
1. Why is 1.0-without-diff not always worse than 3.0 (native) ?
1.0 native is sometimes better than 3.0 (native) because dpkg-source
refuses to build a 3.0 native package with a Debian revision in its
version number.
This prohibition exists solely because of a doctrinal objection to
native-format packages with Debian revisions. There is no technical
reason why this restriction could not be lifted. I sometimes upload
this way and I have never had anyone report problems[1] with it.
IMO there is nothing wrong with native format packages with Debian
revisions. They work just fine. For a small paockage, this is often
a good choice, because it avoids dealing with patches at all.
For anything but a small package, use of diffs is needed as a storage
and distribution optimisation.
2. Why is 1.0-with-diff not always worse than some 3.0 format ?
1.0-with-diff has the following advantage over 3.0 (quilt):
The extracted source tree does not contain a diff. The inclusion of
the diff *inside* the source tree (which happens with "3.0 (quilt)"
whether or not single-debian-patch is specified) causes all manner of
problems: it means that only certain states of the extracted tree are
valid.
With 3.0 and single-debian-patch, modifying ordinary files can
generate a tree which doesn't round-trip through dpkg-source --build
and dpkg-source --extract: dpkg-source --build needs to "commit" the
changes to the diff, amending the working tree.
In other words, the working tree contains output files. This causes
trouble if you want to represent the package in git. This is why dgit
has all this quilt-fixup stuff. With 1.0-with-diff, no quilt fixup is
needed.
3. Why is 1.0-native not just as good as 3.0 (native) ?
The only significant advantage of 3.0 (native) is that dpkg-source is
willing to create and extract 3.0 packages using newer compression
algorithms such as xz.
There were no good reason why the additional compression algorithms
were not supported in 1.0. ("3.0 (native)" does offer some minor
metadata format advantages, so its existence is not entirely
pointless.)
If the restriction against native format with Debian revision were
lifted, "3.0 (native)" would be as capable as 1.0-without-diff, and
slightly superior. So in that case, "3.0 (native)" should probably
replace all uses of 1.0-native.
4. What disadvantages does 1.0-with-diff suffor from, compared to "3.0
(quilt)" with single-debian-patch ?
The main disadvantage is that there are changes to the source tree
which are representable in "3.0 (quilt)" but which 1.0-with-diff does
not support. (The precise details and the history are too compiex to
go into.)
I haven't checked recently, but this used to be enforced both on
building and on extraction. So changing this is not so simple, since
we shouldn't start distributing packages in a new source format (or
variant) until the new extraction capability is very widely deployed.
But, ultimately, it would probably be a good idea. Whether the to
call resulting thing "1.0" or "3.0 (diff)" doesn't really seem very
important.
The important properties are that it should support at least every
change that current diff(1) can represent.
5. Why is native sometimes superior to any quilt or diff format
We rely on diff(1) to represent changes to source trees and patch(1)
to apply them. Not every change is representable by diff.
diff/patch does improve, of course. That is not an unalloyed benefit,
though, because it means that when diff/patch improve we can
accidentally generate source packages that earlier versions can't
extract - a compatibility hazard.
Changes not representable by diff is what Sean is talking about here:
> Ian has some cases where something that is representable in git is not
> representable using 3.0 (quilt) but is representable using 1.0. I don't
> have those cases to hand; Ian, could you summarise, please?
Currently, I think diff cannot represent changes to symlinks.
git can store symlinks and represent their targets, and changes to
their targets.
Ian.
[1] By "problems" I mean "some software did a wrong thing", not
"I am offended by your breach of my notions of propriety".
--
Ian Jackson <ijac...@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.
Ian Jackson
Mar 15, 2022, 3:00:02 PM3/15/22
to
A friend suggested some information that I could usefully provide:
Firstly, I posted to -devel a summary of why format 3.0 is not
pareto-better than 1.0. I have c&p it below.
Secondly, I was asked if there was a bug against src:dpkg asking for
"3.0 (native)" to allow packages with Debian revisions. I don't think
there is - at least, I didn't find one. I do remember this coming up
before, but I don't seem to be able to find a record of it now.
Sean Whitton writes ("Re: Bug#1007717: Native source package format with non-native version"):
to overrule the dpkg maintainer under 6.1.4.
Let me requote myself with annotations:
> On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> > Please:
> >
> > Part I - belss continued use of 1.0 native format, for now at least:
> >
> > 1. Declare explicitly that there is nothing wrong with a package with
> > a native format, but a non-native version number.
6.1(1) Decide on any matter of technical policy.
> > 2. Request that the dpkg maintainer relax the restriction which
> > prevents the use of 3.0 native with Debian revision.
6.1(5) Offer advice.
> > 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.
6.1(5) Offer advice.
> > 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.
6.1(5) Offer advice.
> > 5. Consequently, declare that the recent MBF on this topic ought not
> > to have been filed against 1.0 with diff packages, at least
> > without some further filter.
6.1(5) Offer advice.
Thanks,
Ian.
Firstly, I posted to -devel a summary of why format 3.0 is not
pareto-better than 1.0. I have c&p it below.
Secondly, I was asked if there was a bug against src:dpkg asking for
"3.0 (native)" to allow packages with Debian revisions. I don't think
there is - at least, I didn't find one. I do remember this coming up
before, but I don't seem to be able to find a record of it now.
Sean Whitton writes ("Re: Bug#1007717: Native source package format with non-native version"):
> I think that you are asking us to use 6.1.1/6.1.2 for most of this, but
> for I.3 are you asking for us to use 6.1.4 or 6.1.5? "Request" seems
> more like 6.1.5 but I would like to check.
I think you mean "for I.2 are you asking". I am not asking for the TC
> for I.3 are you asking for us to use 6.1.4 or 6.1.5? "Request" seems
> more like 6.1.5 but I would like to check.
to overrule the dpkg maintainer under 6.1.4.
Let me requote myself with annotations:
> On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> > Please:
> >
> > Part I - belss continued use of 1.0 native format, for now at least:
> >
> > 1. Declare explicitly that there is nothing wrong with a package with
> > a native format, but a non-native version number.
> > 2. Request that the dpkg maintainer relax the restriction which
> > prevents the use of 3.0 native with Debian revision.
> > 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.
> > 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.
> > 5. Consequently, declare that the recent MBF on this topic ought not
> > to have been filed against 1.0 with diff packages, at least
> > without some further filter.
Thanks,
Ian.
Sam Hartman
Mar 15, 2022, 3:00:03 PM3/15/22
to
>>>>> "Ian" == Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
Ian> 3. Consequently, declare that the recent MBF on this topic
Ian> ought not to have been filed against packages where simply
Ian> changing the source format does not currently work. That would
Ian> include at least 1.0 native packages with Debian revisions.
I'm a little confused.
My reading of the debian-devel discussion was that Lucas had already
modified the MBF in a manner consistent with what you're asking for.
It looks like there was a bug in the criteria he used, and it sounds
like he already agrees that a few bugs were filed that should not have
been.
It sounds like he's actively working to fix that.
I think asking the TC to get involved here is a great idea on the
other issues you ask about.
I'm just not sure there is a contraversyfor the TC on the specific
case of the MBF itself.
Ian> 3. Consequently, declare that the recent MBF on this topic
Ian> ought not to have been filed against packages where simply
Ian> changing the source format does not currently work. That would
Ian> include at least 1.0 native packages with Debian revisions.
I'm a little confused.
My reading of the debian-devel discussion was that Lucas had already
modified the MBF in a manner consistent with what you're asking for.
It looks like there was a bug in the criteria he used, and it sounds
like he already agrees that a few bugs were filed that should not have
been.
It sounds like he's actively working to fix that.
I think asking the TC to get involved here is a great idea on the
other issues you ask about.
I'm just not sure there is a contraversyfor the TC on the specific
case of the MBF itself.
Helmut Grohne
Mar 15, 2022, 3:20:04 PM3/15/22
to
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
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.)
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.
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.
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
Felix Lechner
Mar 15, 2022, 3:30:03 PM3/15/22
to
Hi Ian,
On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson
<ijac...@chiark.greenend.org.uk> wrote:
>
> I do remember this coming up
> before, but I don't seem to be able to find a record of it now.
Perhaps you were thinking about this discussion in a bug against Lintian?
Ideally I would like dpkg-source to permit source format
`3.0 (native)' packages to have a non-native version number. [1]
Kind regards,
Felix Lechner
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#30
On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson
<ijac...@chiark.greenend.org.uk> wrote:
>
> I do remember this coming up
> before, but I don't seem to be able to find a record of it now.
Ideally I would like dpkg-source to permit source format
`3.0 (native)' packages to have a non-native version number. [1]
Kind regards,
Felix Lechner
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#30
Lucas Nussbaum
Mar 15, 2022, 5:20:04 PM3/15/22
to
Hi,
First, some context with numbers:
Source packages in testing: 32247
Source packages in testing using 3.0 (native): 690 (2.1%)
Source packages in testing using 3.0 (quilt): 30937 (95.9%)
Source packages in testing using 1.0: 620 (1.9%)
Those 620 packages probably fit in two categories:
A) those whose maintainers are inactive, or unaware that the
package uses 1.0, and would switch to 3.0 if they knew about it
B) those whose maintainers choose to stay with 1.0 for a reason
Estimating the number of packages in both categories in difficult.
Packages obviously in (B) are those maintained by the Debian X team,
by iwj, by tfheen, or by az. Those that provide debian/source/format
are also good candidates (but there might be some false positives).
The number of each case and for the combination of both are:
... with explicit debian/source/format: 178
... maintained or co-maintained by Debian X, iwj, tfheen, az: 129
... with explicit debian/source/format OR maintained or
co-maintained by Debian X, iwj, tfheen, az: 262 (0.8%)
So, we are talking about approximately 0.8% of packages here.
There's a page at https://udd.debian.org/cgi-bin/format10.cgi that
allows exploring the list of packages (the classification criteria are
the ones used for the MBF, not the ones above).
There are also graphs at
https://trends.debian.net/#source-formats-and-patch-systems to see the
evolution over time.
On 15/03/22 at 20:08 +0100, Helmut Grohne wrote:
> 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.
I do not plan to upgrade the severity of the bugs, nor to file other
bugs. I am fine with maintainers/co-maintainers closing bugs (especially
with a rationale), and do not plan to reopen bugs that will be closed. I
do not plan to try to do further cleanup using a more complex heuristic
as I think that it's valuable to use those bugs to further identify
what are the blocking factors for migration to 3.0.
I can agree that the heuristic to determine which packages to file bugs
against could have been designed better. However, given that it's
impossible to read maintainers' mind, it's probably impossible to
achieve perfection here. (For example, I identified that the Debian X
team was using 1.0 with a specific workflow and excluded its packages, I
should probably have excluded Ian's packages as well, but only
discovered the objection of other maintainers because I did the MBF.)
A point that I find important is the following: as a project, I think
that we care about facilitating the review of changes we make to
upstream source. I think that the preferred method (and widely accepted
method) for that is currently to use the 3.0 (quilt) format with
DEP-3-documented patches, on top of a tarball that contains the pristine
upstream source.
The git packaging workflows that generate source packages using either
1.0 native packages, or 1.0 non-native packages without patches, make it
harder to identify and review those changes, as they require browsing
the git repository, which sometimes is not properly documented using
Vcs-*.
I do not think that the practice of making "fake" native source packages
should be encouraged by allowing 3.0 (native) packages to have Debian
revisions.
So my "ideal" TC ruling on those matters would be something along the
lines of:
- Use of 3.0 (quilt) or 3.0 (native) is recommended
- Use of 1.0 is discouraged
- After a proper work to identify affected packages and notify
maintainers in advance, providing a debian/source/format file
can be made mandatory to accelerate the transition to 3.0 (which the
ability for packages to stay with 1.0 if explicit)
- Packages still using 1.0 must provide an adequate way to review Debian
changes, such as a functional VCS repository.
- Maintainers that rely on workflows that require the use of 1.0 are
encouraged to explore how to move to 3.0 without compromising the
capability to review changes using the source package.
Lucas
First, some context with numbers:
Source packages in testing: 32247
Source packages in testing using 3.0 (native): 690 (2.1%)
Source packages in testing using 3.0 (quilt): 30937 (95.9%)
Source packages in testing using 1.0: 620 (1.9%)
Those 620 packages probably fit in two categories:
A) those whose maintainers are inactive, or unaware that the
package uses 1.0, and would switch to 3.0 if they knew about it
B) those whose maintainers choose to stay with 1.0 for a reason
Estimating the number of packages in both categories in difficult.
Packages obviously in (B) are those maintained by the Debian X team,
by iwj, by tfheen, or by az. Those that provide debian/source/format
are also good candidates (but there might be some false positives).
The number of each case and for the combination of both are:
... with explicit debian/source/format: 178
... maintained or co-maintained by Debian X, iwj, tfheen, az: 129
... with explicit debian/source/format OR maintained or
co-maintained by Debian X, iwj, tfheen, az: 262 (0.8%)
So, we are talking about approximately 0.8% of packages here.
There's a page at https://udd.debian.org/cgi-bin/format10.cgi that
allows exploring the list of packages (the classification criteria are
the ones used for the MBF, not the ones above).
There are also graphs at
https://trends.debian.net/#source-formats-and-patch-systems to see the
evolution over time.
On 15/03/22 at 20:08 +0100, Helmut Grohne wrote:
> 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.
bugs. I am fine with maintainers/co-maintainers closing bugs (especially
with a rationale), and do not plan to reopen bugs that will be closed. I
do not plan to try to do further cleanup using a more complex heuristic
as I think that it's valuable to use those bugs to further identify
what are the blocking factors for migration to 3.0.
I can agree that the heuristic to determine which packages to file bugs
against could have been designed better. However, given that it's
impossible to read maintainers' mind, it's probably impossible to
achieve perfection here. (For example, I identified that the Debian X
team was using 1.0 with a specific workflow and excluded its packages, I
should probably have excluded Ian's packages as well, but only
discovered the objection of other maintainers because I did the MBF.)
A point that I find important is the following: as a project, I think
that we care about facilitating the review of changes we make to
upstream source. I think that the preferred method (and widely accepted
method) for that is currently to use the 3.0 (quilt) format with
DEP-3-documented patches, on top of a tarball that contains the pristine
upstream source.
The git packaging workflows that generate source packages using either
1.0 native packages, or 1.0 non-native packages without patches, make it
harder to identify and review those changes, as they require browsing
the git repository, which sometimes is not properly documented using
Vcs-*.
I do not think that the practice of making "fake" native source packages
should be encouraged by allowing 3.0 (native) packages to have Debian
revisions.
So my "ideal" TC ruling on those matters would be something along the
lines of:
- Use of 3.0 (quilt) or 3.0 (native) is recommended
- Use of 1.0 is discouraged
- After a proper work to identify affected packages and notify
maintainers in advance, providing a debian/source/format file
can be made mandatory to accelerate the transition to 3.0 (which the
ability for packages to stay with 1.0 if explicit)
- Packages still using 1.0 must provide an adequate way to review Debian
changes, such as a functional VCS repository.
- Maintainers that rely on workflows that require the use of 1.0 are
encouraged to explore how to move to 3.0 without compromising the
capability to review changes using the source package.
Lucas
Sam Hartman
Mar 15, 2022, 11:50:03 PM3/15/22
to
Dear TC,
I cannot speak for what Ian wants,
but I would also like to formally ask the TC to rule on this issue.
My hope is that what Ian and I are asking for is similar enough that the
TC can consider the issues together.
Specifically, I'd like to ask the TC to come up with policy on native
packages and debian revisions using its power under 6.1.1.
In particular I ask the TC to consider the hypothesis that:
* Debian revisions are useful when there is a separate upstream flow
from the packaging flow. For example when Debian versions are
released at different times than upstream times, Debian versions have
different content (for example a debian directory), or Debian versions
are maintained by different people. IN these cases a debian revision
may be useful.
* Native source package formats (1.0 tar only and 3.0 (native)) are
useful when the work flow
is easier to maintain without separated Debian changes. There are
several cases involving git work flows where package maintenance is
improved by not requiring this separation.
* Git work flows are a best practice. There may be other best practices
too. We want to encourage git work flows to become more streamlined
and easier; when people have found git work flows that make their job
as maintainers easier, we want to encourage that.
I don't think the TC needs to do out-of-charter design work to come up
with policy in this regard.
I think there's been a lot of work within debian-policy, within
discussions of git packaging flows, and within the consensus-seeking
discussions run over the years.
I'll point outt that the behavior of non-experimental package
building tools explicitly falls under 6.1.1 and does not require the TC
to override a maintainer.
I believe it is also appropriate for the TC to rule under 6.1.2.
It's clear that policy, the packaging tools, archive build tools, and
tools to support git work flows need to be in harmony for things to work
well.
It's clear there is overlap, and it is clear to me we do not have
harmony today.
I'd also like to provide some initial briefing material to the TC to
help you all come up to speend on this issue.
* Ian's mail that you were forwarded
* #bug 737634
* My messages starting at
https://lists.debian.org/00000144017b42b6-b65ba883-c94b...@email.amazonses.com
and following the thread. I explain one case where you want to use
a debian revision with native packages. I think Ian has described
cases that are more clearly directly related to the Debian archive,
but I clearly outline in that bug report problems I was having and
why proposed alternatives did not work.
* Around that time a claim was made that debian-policy did not permit
debian revisions with native packages. I challenged that claim and in
https://lists.debian.org/8761otp...@windlord.stanford.edu Russ
acknowledges that the section of policy he was pointing at did not
actually forbid debian revisions with native packages. So at the time
dpkg made the change it was breaking things and there was no policy
requirement for the change.
* Ubuntu had to make a change to dpkg-source at least as used by
launchpad for recipe builds to continue to work. I don't know if they
still maintain that patch, but it seems like a bad sign when a major
downstream needs to revert a change we've done to get work done. It
would perhaps be valuable to look into whether they still have that
delta and if not how they work around things.
* https://lists.debian.org/tsla738...@suchdamage.org the most
interesting bit there is a consensus of the project that if your
upstream uses git, best practice is for your packaging to use git.
* https://lists.debian.org/tslr252io...@suchdamage.org Consensus:
native packages are sometimes an appropriate tool to use in contrast
to earlier consensus that we wanted to move away from them.
* Plus the recent thread on debian-devel.
* The git packaging BOF at DebConf19.
Thanks for your consideration,
--Sam
Russ Allbery
Mar 16, 2022, 12:40:03 AM3/16/22
to
Sam Hartman <hart...@debian.org> writes:
> Specifically, I'd like to ask the TC to come up with policy on native
> packages and debian revisions using its power under 6.1.1.
As a Policy Editor, I support this request.
> Specifically, I'd like to ask the TC to come up with policy on native
> packages and debian revisions using its power under 6.1.1.
I've been involved in a lot of these discussions over the years, and the
tentative conclusion that I've come to is that we have unfortunately mixed
several different concepts in how we talk about source packages. This has
not *technically* reduced the flexibility of the packaging format because
there are various workarounds, but it's *conceptually* reduced the
flexibility in a way that makes those workarounds look conceptually
incorrect. As a result, we have constant repetitions of similar arguments
stemming from well-meaning attempts to clean up the apparent
inconsistencies (including some I have started).
There are really two separate concepts in play here:
1. Different version numbering conventions for native and non-native
packages. For non-native packages, we want to preserve the upstream
version number as much as possible so that our users can correlate our
packages to upstream releases. We therefore have the Debian revision
component of the version number. But we don't want to use that
component for native packages, since there is no corresponding upstream
version.
And I do believe that we need to keep the concept of native packages.
There are configuration-only packages, metapackages, and other cases
where even with an extremely aggressive idea of what should entail a
separate upstream release, a separate upstream makes no sense. And I
can also confirm that outside of Debian native packages are heavily
used by Debian users to package local things.
2. Source package formats. Here, people want different things based on
different workflows. We may have opinions about which workflows are
better and which are worse, but by and large Debian tries to provide
room for innovation on workflows, and there are some important
workflows outside of the archive (such as automated builds from CI as
Sam has mentioned) where simplicity is far more important than careful
tracking of distinctions between upstream and Debian changes.
There is a clearly-expressed desire to support a package format with as
simple of a representation as possible for some of those workflows,
either because the complexity is being handled at another level or
because the complexity is make-work for the desired goal that isn't
worth doing (true for a lot of out-of-archive use cases).
The current native format of a single tarball that you unpack and can
then build as a Debian package with no further work is exactly what
many of those workflows want.
We have conflated 1 and 2, but I don't think they are as closely related
as the project has conceptually presented them. There is a tie in that
*if* there is a separate upstream release, then someone may want a package
format that allows keeping the Debian pieces and the upstream pieces
clearly separate. But in practice there are reasons to want to use the
single-tarball source format for a non-native package.
(I admit I am unable to think of a plausible reason to use the multiple
tarball or tarball with patch format for a native package, but that may be
a failure of my imagination. I can think of some space-conserving reasons
to want to use that packaging format if the archive would reuse the
tarballs, but the archive software won't when using native versioning, and
changing that would be extremely difficult and probably not worth the
effort.)
What I would propose is to separate these concepts cleanly so that we can
talk about them in a clearer way. We should define native and non-native
packages in terms of version numbers, and allow both native and non-native
packages to use single-tarball source package formats. We may want to
steer people away from using the single-tarball source package format for
the *normal* case of packaging upstream software, but I think it's well
within the sorts of trade-off decisions that packagers already make and
there are cases where a single tarball source format makes sense.
The name of the 3.0 (native) source package format is unfortunate in this
context since it strongly implies that only native packages will use that
source format. The most formally correct thing to do would probably be to
introduce a new 3.0 (single-tarball) source format and use 1.0 until then,
but of course introducing a new source package format is not a fast
process. A more expedient thing to do may be to allow use of 3.0 (native)
with non-native packages, since it's identical to 3.0 (single-tarball)
except for the name, but it does leave a long-term confusing naming scheme
in place. Guillem may well have other and better suggestions from the
dpkg perspective; I haven't thought all that much about a transition plan.
Note that this only addresses the first part of Ian's request. The second
part, the 1.0 with patches format, I believe stems from different problems
with the 3.0 (quilt) format that are unrelated to the native vs.
non-native package distinction. I have no useful opinions to add on that
topic.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Felix Lechner
Mar 16, 2022, 11:10:03 AM3/16/22
to
Hi,
On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery <r...@debian.org> wrote:
>
> We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats.
I co-maintaintain several Debian-internal tools, and that description
is backwards. "Native" sources are characterized by their lack of
Debian patches.
On that note, the term "native" is also not great. The words "patched"
and "unpatched" describe the relationship between sources in the
archive and their respective upstreams more accurately.
As for version strings, we need no additional restrictions. The use of
patches is declared in source format 3.0. Some folks even use Debian
revisions for unpatched sources. [1]
Most significantly, Lintian's parser is unable to deduce "nativeness"
from the version number. The native status is a required input! [2]
Please do not "define" a source's patch status via the version string.
It's what got us here in the first place. Debian version numbers are
complicated enough already. Thank you!
Kind regards,
Felix Lechner
[1] for example, https://tracker.debian.org/pkg/python3-defaults
[2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Changelog/Version.pm#L79-80
On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery <r...@debian.org> wrote:
>
> We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats.
is backwards. "Native" sources are characterized by their lack of
Debian patches.
On that note, the term "native" is also not great. The words "patched"
and "unpatched" describe the relationship between sources in the
archive and their respective upstreams more accurately.
As for version strings, we need no additional restrictions. The use of
patches is declared in source format 3.0. Some folks even use Debian
revisions for unpatched sources. [1]
Most significantly, Lintian's parser is unable to deduce "nativeness"
from the version number. The native status is a required input! [2]
Please do not "define" a source's patch status via the version string.
It's what got us here in the first place. Debian version numbers are
complicated enough already. Thank you!
Kind regards,
Felix Lechner
[1] for example, https://tracker.debian.org/pkg/python3-defaults
[2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Changelog/Version.pm#L79-80
Ian Jackson
Mar 16, 2022, 11:40:03 AM3/16/22
to
Helmut Grohne writes ("Re: Bug#1007717: Native source package format with non-native version"):
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.
> 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
> 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.
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.
(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.
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.
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.
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.
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.
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.
Russ Allbery
Mar 16, 2022, 12:00:03 PM3/16/22
to
Felix Lechner <felix....@lease-up.com> writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery <r...@debian.org> wrote:
>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.
> I co-maintaintain several Debian-internal tools, and that description is
> backwards. "Native" sources are characterized by their lack of Debian
> patches.
This is exactly the semantic confusion that I believe is wrong and we
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery <r...@debian.org> wrote:
>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.
> I co-maintaintain several Debian-internal tools, and that description is
> backwards. "Native" sources are characterized by their lack of Debian
> patches.
should undo. "Native" vs. "non-native" should be a property of the
relationship between the package and a separate upstream release, which is
represented in the version. That should be decoupled from the source
package format.
The point that Ian and Sam are raising is that a single tarball is a good
way of representing the Debian package source in several non-native cases
where we are still packaging a piece of software with an independent
upstream existence, and where having a version with a Debian revision is
still semantically correct.
> On that note, the term "native" is also not great. The words "patched"
> and "unpatched" describe the relationship between sources in the archive
> and their respective upstreams more accurately.
non-native packages to switch between patched and unpatched from upload to
upload, depending on whether Debian has to carry additional patches,
without any change in their version number format or in the source package
format. This is correct and should continue to be supported.
Wookey
Mar 16, 2022, 8:00:03 PM3/16/22
to
On 2022-03-16 15:29 +0000, Ian Jackson wrote:
> In practice, the vast majority of packages are maintained in git on
> salsa. The maintainers use those git repositories as the PFM.
> In practice, the vast majority of packages are maintained in git on
> salsa. The maintainers use those git repositories as the PFM.
> but almost everyone is already treating git as primary.
Is this definitely true? For example: I know I'm not doing this. I did
try, and I do have some git repos on salsa, but I've mostly given up
with it all and stuck with uscan and tarballs and quilt (and my trusty
'packages' directory). It's much easier for me. (The salsa repos that
exist for my packages are not canonical and often stale).
I'm sure Ian is right that there is a trend towards git from tarballs
and dscs, but I just question whether we know it is 'the vast
majority'? Are there really now very few maintainers using the
'classic tooling'? How do we know?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
Helmut Grohne
Mar 17, 2022, 3:00:04 AM3/17/22
to
Hi Russ,
On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
> > Specifically, I'd like to ask the TC to come up with policy on native
> > packages and debian revisions using its power under 6.1.1.
>
> As a Policy Editor, I support this request.
As a TC member I admit disliking this. While there is disagreement on
how things are supposed to work, the views don't seem to be that far
apart. Urgency is effectively removed by Lucas agreeing to pause further
deprecation work. Do you think it would be impossible to move forward on
this matter in a consensus-based way?
> I've been involved in a lot of these discussions over the years, and the
> tentative conclusion that I've come to is that we have unfortunately mixed
> several different concepts in how we talk about source packages. This has
> not *technically* reduced the flexibility of the packaging format because
> there are various workarounds, but it's *conceptually* reduced the
> flexibility in a way that makes those workarounds look conceptually
> incorrect. As a result, we have constant repetitions of similar arguments
> stemming from well-meaning attempts to clean up the apparent
> inconsistencies (including some I have started).
While I did point out the conflation of matters in my initial reply to
Ian, I didn't put it as clearly as you did. Thank you. In the later
replies to your mail, we see that even trying to disentangle this is
difficult terminology-wise.
> There are really two separate concepts in play here:
I am wondering whether maybe one of you could work on a consensus
seeking process about these matters. I believe that resolving this using
consensus is far better than having 8 semi-random people decide upon a
policy. The consensus-based approach does not seem impossible to me at
this stage.
> What I would propose is to separate these concepts cleanly so that we can
> talk about them in a clearer way. We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats. We may want to
> steer people away from using the single-tarball source package format for
> the *normal* case of packaging upstream software, but I think it's well
> within the sorts of trade-off decisions that packagers already make and
> there are cases where a single tarball source format makes sense.
Yes, please. Though as is evidenced in the replies to your mail, I would
try to avoid "native" and "non-native" as much as possible given the
existing confusion. I suggest using something like with-revision vs
without-revision and single-tarball (from your mail) vs
patches-separated to transport the concepts. Of course "3.0 (native)" as
the content of debian/source/format cannot be avoided, but we can
describe its current and possibly desired properties in a less confusing
way.
> The name of the 3.0 (native) source package format is unfortunate in this
> context since it strongly implies that only native packages will use that
> source format. The most formally correct thing to do would probably be to
> introduce a new 3.0 (single-tarball) source format and use 1.0 until then,
> but of course introducing a new source package format is not a fast
> process. A more expedient thing to do may be to allow use of 3.0 (native)
> with non-native packages, since it's identical to 3.0 (single-tarball)
> except for the name, but it does leave a long-term confusing naming scheme
> in place. Guillem may well have other and better suggestions from the
> dpkg perspective; I haven't thought all that much about a transition plan.
More and more, it seems to me that we are looking into design work as
opposed to picking an existing option. I think it is preferable to do
that with "normal" Debian processes without involving the TC, because
the latter always comes with constitutional powers attached (used or
unused). If history has taught us anything, involving the TC always
comes with escalation. We may still reach a point where it is clear that
consensus is not possible, but I don't think we're there yet.
In the spirit of consensus: Do you agree that retrying this in a
consensus-based way is still possible?
Helmut
On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
> > Specifically, I'd like to ask the TC to come up with policy on native
> > packages and debian revisions using its power under 6.1.1.
>
> As a Policy Editor, I support this request.
how things are supposed to work, the views don't seem to be that far
apart. Urgency is effectively removed by Lucas agreeing to pause further
deprecation work. Do you think it would be impossible to move forward on
this matter in a consensus-based way?
> I've been involved in a lot of these discussions over the years, and the
> tentative conclusion that I've come to is that we have unfortunately mixed
> several different concepts in how we talk about source packages. This has
> not *technically* reduced the flexibility of the packaging format because
> there are various workarounds, but it's *conceptually* reduced the
> flexibility in a way that makes those workarounds look conceptually
> incorrect. As a result, we have constant repetitions of similar arguments
> stemming from well-meaning attempts to clean up the apparent
> inconsistencies (including some I have started).
Ian, I didn't put it as clearly as you did. Thank you. In the later
replies to your mail, we see that even trying to disentangle this is
difficult terminology-wise.
> There are really two separate concepts in play here:
seeking process about these matters. I believe that resolving this using
consensus is far better than having 8 semi-random people decide upon a
policy. The consensus-based approach does not seem impossible to me at
this stage.
> What I would propose is to separate these concepts cleanly so that we can
> talk about them in a clearer way. We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats. We may want to
> steer people away from using the single-tarball source package format for
> the *normal* case of packaging upstream software, but I think it's well
> within the sorts of trade-off decisions that packagers already make and
> there are cases where a single tarball source format makes sense.
try to avoid "native" and "non-native" as much as possible given the
existing confusion. I suggest using something like with-revision vs
without-revision and single-tarball (from your mail) vs
patches-separated to transport the concepts. Of course "3.0 (native)" as
the content of debian/source/format cannot be avoided, but we can
describe its current and possibly desired properties in a less confusing
way.
> The name of the 3.0 (native) source package format is unfortunate in this
> context since it strongly implies that only native packages will use that
> source format. The most formally correct thing to do would probably be to
> introduce a new 3.0 (single-tarball) source format and use 1.0 until then,
> but of course introducing a new source package format is not a fast
> process. A more expedient thing to do may be to allow use of 3.0 (native)
> with non-native packages, since it's identical to 3.0 (single-tarball)
> except for the name, but it does leave a long-term confusing naming scheme
> in place. Guillem may well have other and better suggestions from the
> dpkg perspective; I haven't thought all that much about a transition plan.
opposed to picking an existing option. I think it is preferable to do
that with "normal" Debian processes without involving the TC, because
the latter always comes with constitutional powers attached (used or
unused). If history has taught us anything, involving the TC always
comes with escalation. We may still reach a point where it is clear that
consensus is not possible, but I don't think we're there yet.
In the spirit of consensus: Do you agree that retrying this in a
consensus-based way is still possible?
Helmut
Lucas Nussbaum
Mar 17, 2022, 3:40:03 AM3/17/22
to
If you look at https://trends.debian.net/#version-control-system, I
think it's fair to say that the vast majority of packages are now
maintained in git.
And if you look at the status of those repositories according to
vswatch, most of them are actively used:
udd=> select status, count(distinct source) from vcswatch group by status order by 2;
status | count
---------+-------
UNREL | 119
OLD | 1218
ERROR | 1328
COMMITS | 3620
NEW | 7127
OK | 17873
(the last three lines being 'normal' states.)
Lucas
Sam Hartman
Mar 17, 2022, 10:40:04 AM3/17/22
to
>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes:
Helmut> Hi Russ,
Helmut> disagreement on how things are supposed to work, the views
Helmut> don't seem to be that far apart. Urgency is effectively
Helmut> removed by Lucas agreeing to pause further deprecation
Helmut> work. Do you think it would be impossible to move forward on
Helmut> this matter in a consensus-based way?
I think this is like usrmerge.
I actually think there is a rough consensus, but there are one or two
parties who find that consensus unacceptable and who are in a position
to block the consensus.
As an example, the text in policy 5.6.12 has been significantly revised
since Russ and I started discussing this issue in 2014.
It's possible that policy could be improved, but honestly I think that
policy is already consistent with the hypothesis I presented to the TC.
I also already tried to seek consensus where this is possible as DPL,
and included a pointer to my consensus call on the issues where there
was consensus in the material I already presented to the TC.
This is a case where people have slowly been building consensus since
2014. One of the key stakeholders has not effectively participated
constructively, and so some things haven't been possible.
We're asking the TC to do the last mile work--review the existing
consensus-forming discussions, figure out where we are, and wrap it up
just like you did with usrmerge.
I've even tried to give you the key discussions that happened on
debian-devel.
I suspect one of the policy editors could go pull that together for
discussions on debian-policy, but if not, I'd be happy to do that work
if requested.
So, no, I do think this is ready for the TC to finish things up now.
--Sam
Helmut> Hi Russ,
Helmut> On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
>> > Specifically, I'd like to ask the TC to come up with policy on
>> native > packages and debian revisions using its power under
>> 6.1.1.
>>
>> As a Policy Editor, I support this request.
Helmut> As a TC member I admit disliking this. While there is
>> > Specifically, I'd like to ask the TC to come up with policy on
>> native > packages and debian revisions using its power under
>> 6.1.1.
>>
>> As a Policy Editor, I support this request.
Helmut> disagreement on how things are supposed to work, the views
Helmut> don't seem to be that far apart. Urgency is effectively
Helmut> removed by Lucas agreeing to pause further deprecation
Helmut> work. Do you think it would be impossible to move forward on
Helmut> this matter in a consensus-based way?
I think this is like usrmerge.
I actually think there is a rough consensus, but there are one or two
parties who find that consensus unacceptable and who are in a position
to block the consensus.
As an example, the text in policy 5.6.12 has been significantly revised
since Russ and I started discussing this issue in 2014.
It's possible that policy could be improved, but honestly I think that
policy is already consistent with the hypothesis I presented to the TC.
I also already tried to seek consensus where this is possible as DPL,
and included a pointer to my consensus call on the issues where there
was consensus in the material I already presented to the TC.
This is a case where people have slowly been building consensus since
2014. One of the key stakeholders has not effectively participated
constructively, and so some things haven't been possible.
We're asking the TC to do the last mile work--review the existing
consensus-forming discussions, figure out where we are, and wrap it up
just like you did with usrmerge.
I've even tried to give you the key discussions that happened on
debian-devel.
I suspect one of the policy editors could go pull that together for
discussions on debian-policy, but if not, I'd be happy to do that work
if requested.
So, no, I do think this is ready for the TC to finish things up now.
--Sam
Russ Allbery
Mar 17, 2022, 2:00:04 PM3/17/22
to
Helmut Grohne <hel...@subdivi.de> writes:
> Do you think it would be impossible to move forward on this matter in a
> consensus-based way?
I don't know. I have some reasons to be dubious, but it's possible that
> Do you think it would be impossible to move forward on this matter in a
> consensus-based way?
I'm being excessively pessimistic.
> Yes, please. Though as is evidenced in the replies to your mail, I would
> try to avoid "native" and "non-native" as much as possible given the
> existing confusion. I suggest using something like with-revision vs
> without-revision and single-tarball (from your mail) vs
> patches-separated to transport the concepts.
meanings isn't a bad idea, but if so we really need a term that captures
"is a packaging of an upstream software package with a separate existence"
versus "exists solely as a Debian package." "with-revision" or
"without-revision" doesn't feel to me like it does this. Native and
non-native do, which is why I was sticking with them, but maybe we can
come up with some other equally-good terminology.
> More and more, it seems to me that we are looking into design work as
> opposed to picking an existing option.
The point was to offer you a design to consider as part of submitting the
request to the TC.
> In the spirit of consensus: Do you agree that retrying this in a
> consensus-based way is still possible?
tackle it that way, I am certainly willing to participate from the Policy
side.
Sam Hartman
Mar 17, 2022, 2:30:05 PM3/17/22
to
>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
Russ> Switching terminology to completely leave behind the terms
Russ> with ambiguous meanings isn't a bad idea, but if so we really
Russ> need a term that captures "is a packaging of an upstream
Russ> software package with a separate existence" versus "exists
Russ> solely as a Debian package." "with-revision" or
Russ> "without-revision" doesn't feel to me like it does this.
Russ> Native and non-native do, which is why I was sticking with
Russ> them, but maybe we can come up with some other equally-good
Russ> terminology.
Why do we need that distinction?
Looking at current policy, 5.6.12 talks about having a debian revision
or not having a debian revision.
Other parts of policy talk about what parts of the source package there
are.
Why do we need more than these two distinctions.
I think that current policy has mostly left behind the work native
(although their are a few uses still).
My suspicion is that avoiding native allowed us to get a broader
consensus in the policy process.
Why isn't what we have good enough?
Russ> Switching terminology to completely leave behind the terms
Russ> with ambiguous meanings isn't a bad idea, but if so we really
Russ> need a term that captures "is a packaging of an upstream
Russ> software package with a separate existence" versus "exists
Russ> solely as a Debian package." "with-revision" or
Russ> "without-revision" doesn't feel to me like it does this.
Russ> Native and non-native do, which is why I was sticking with
Russ> them, but maybe we can come up with some other equally-good
Russ> terminology.
Why do we need that distinction?
Looking at current policy, 5.6.12 talks about having a debian revision
or not having a debian revision.
Other parts of policy talk about what parts of the source package there
are.
Why do we need more than these two distinctions.
I think that current policy has mostly left behind the work native
(although their are a few uses still).
My suspicion is that avoiding native allowed us to get a broader
consensus in the policy process.
Why isn't what we have good enough?
Russ Allbery
Mar 17, 2022, 3:00:04 PM3/17/22
to
Sam Hartman <hart...@debian.org> writes:
>>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures "is a packaging of an upstream
> Russ> software package with a separate existence" versus "exists
> Russ> solely as a Debian package." "with-revision" or
> Russ> "without-revision" doesn't feel to me like it does this.
> Russ> Native and non-native do, which is why I was sticking with
> Russ> them, but maybe we can come up with some other equally-good
> Russ> terminology.
> Why do we need that distinction?
I think we need some way to talk about the various things that change
>>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures "is a packaging of an upstream
> Russ> software package with a separate existence" versus "exists
> Russ> solely as a Debian package." "with-revision" or
> Russ> "without-revision" doesn't feel to me like it does this.
> Russ> Native and non-native do, which is why I was sticking with
> Russ> them, but maybe we can come up with some other equally-good
> Russ> terminology.
> Why do we need that distinction?
about a package if it is a packaging of an upstream package. Examples
include a debian/watch file, an upstream metadata file, an upstream
signing key (still useful with single-tarball formats if upstream uses
signed tags, etc.), and provenance information in debian/copyright.
Those things are not tied to the source package format. We want
provenance information for the upstream source even if you're using a
single tarball as a source package format, but we don't need it if there
is no upstream.
> Looking at current policy, 5.6.12 talks about having a debian revision
> or not having a debian revision.
number format, rather than having the version number format indicate
whether this is a packaging of an upstream source with an independent
existence. That would imply that if you just omit the debian revision,
you don't need to record the provenance of the upstream source, which
doesn't seem correct.
Felix Lechner
Mar 17, 2022, 3:50:03 PM3/17/22
to
Hi,
On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery <r...@debian.org> wrote:
>
> source package format
While everyone is receptive to new labels, I prefer "upload format" or
"archive format". Either one helps us to distinguish the intermediate
product from any workflow objects a maintainer may have.
> single tarball as a source package format
It is also not necessary to "define" unpatched sources in the archive
by how many tarballs they have, or any tarballs at all.
In fact, I wrote a manifest utility that could one day replace tarball
signatures with per-file hashes. The latter remain useful even when
sources are repackaged, because manifests can be cryptographically
daisy-chained in a "chain of custody." Of course, they would be more
often used for patched upload formats.
Kind regards
Felix Lechner
On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery <r...@debian.org> wrote:
>
> source package format
While everyone is receptive to new labels, I prefer "upload format" or
"archive format". Either one helps us to distinguish the intermediate
product from any workflow objects a maintainer may have.
> single tarball as a source package format
by how many tarballs they have, or any tarballs at all.
In fact, I wrote a manifest utility that could one day replace tarball
signatures with per-file hashes. The latter remain useful even when
sources are repackaged, because manifests can be cryptographically
daisy-chained in a "chain of custody." Of course, they would be more
often used for patched upload formats.
Kind regards
Felix Lechner
Lucas Nussbaum
Mar 17, 2022, 5:40:03 PM3/17/22
to
Hi Ian,
On 15/03/22 at 16:29 +0000, Ian Jackson wrote:
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
>
> 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.
>
> 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.
>
> 5. Consequently, declare that the recent MBF on this topic ought not
> to have been filed against 1.0 with diff packages, at least
> without some further filter.
I did the MBF mentioned in (5) (about suggesting the move from the 1.0
format to one of the 3.0 formats), and agreed to pause those efforts in
<YjD/8hqJ/zqE...@xanadu.blop.info>.
However, it might be worth clarifying if the MBF in (3) is mine, or
Guillem's one (with usertag dpkg-mismatch-source-vs-version-format and
user debia...@lists.debian.org) about "Mismatched source format vs
source version" (an example bug is #1007088). I think it's mine, but I'm
not sure. It might also be both.
Lucas
On 15/03/22 at 16:29 +0000, Ian Jackson wrote:
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
>
> 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.
>
> 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.
>
> 5. Consequently, declare that the recent MBF on this topic ought not
> to have been filed against 1.0 with diff packages, at least
> without some further filter.
format to one of the 3.0 formats), and agreed to pause those efforts in
<YjD/8hqJ/zqE...@xanadu.blop.info>.
However, it might be worth clarifying if the MBF in (3) is mine, or
Guillem's one (with usertag dpkg-mismatch-source-vs-version-format and
user debia...@lists.debian.org) about "Mismatched source format vs
source version" (an example bug is #1007088). I think it's mine, but I'm
not sure. It might also be both.
Lucas
Matthew Vernon
Mar 20, 2022, 12:40:03 PM3/20/22
to
On 17/03/2022 17:52, Russ Allbery wrote:
> Helmut Grohne <hel...@subdivi.de> writes:
>
>> Do you think it would be impossible to move forward on this matter in a
>> consensus-based way?
>
> I don't know. I have some reasons to be dubious, but it's possible that
> I'm being excessively pessimistic.
I'm inclined to agree with Russ here; my impression is there are one or
> Helmut Grohne <hel...@subdivi.de> writes:
>
>> Do you think it would be impossible to move forward on this matter in a
>> consensus-based way?
>
> I don't know. I have some reasons to be dubious, but it's possible that
> I'm being excessively pessimistic.
two long-standing areas of disagreement here, and that consensus hasn't
been arrived at.
>> In the spirit of consensus: Do you agree that retrying this in a
>> consensus-based way is still possible?
>
> If the relevant people required to implement a decision are willing to
> tackle it that way, I am certainly willing to participate from the Policy
> side.
suggest the TC gets in the way!
Regards,
Matthew
Lucas Nussbaum
Mar 29, 2022, 3:40:05 PM3/29/22
to
Hi Sean,
On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
> Hello Lucas,
>
> Many thanks for providing this summary of your position. Let me just
> note a point of disagreement:
> sees git histories are the preferred tool for achieving the goal you
> state.
>
> If we had only source packages for this purpose, then yes, 3.0 (quilt)
> plus DEP-3 would be preferred. But we have git, too, and indeed dgit.
> Repositories for packages contain both upstream history and Debian
> packaging history, and we have powerful git subcommands for extracting
> information. In many cases there is a good argument to be made that the
> git history is part of the preferred form of modification.
I think there are three different use cases to consider:
A. preferred form for regular contributions to the package (typically
by the package maintainer)
B. preferred form for occasional contributions to the package (typically
by an NMUer, or by the security team)
C. preferred form for reviewing the packaging and Debian-specific
changes.
I fully agree that the git repository is the preferred form for A.
However, for B and C, I think that our lingua franca is the source
package, and thus a source package that doesn't make it hard to
understand things such as Debian-specific patches. Of course that
could change if we were able to standardize on a git workflow (or
a small set of git workflows), but I don't see this happenning anytime
soon.
Lucas
On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
> Hello Lucas,
>
> Many thanks for providing this summary of your position. Let me just
> note a point of disagreement:
>
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
>
> > A point that I find important is the following: as a project, I think
> > that we care about facilitating the review of changes we make to
> > upstream source.
>
> Certainly we do.
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
>
> > A point that I find important is the following: as a project, I think
> > that we care about facilitating the review of changes we make to
> > upstream source.
>
>
> > I think that the preferred method (and widely accepted method) for
> > that is currently to use the 3.0 (quilt) format with DEP-3-documented
> > patches, on top of a tarball that contains the pristine upstream
> > source.
> >
> > The git packaging workflows that generate source packages using either
> > 1.0 native packages, or 1.0 non-native packages without patches, make it
> > harder to identify and review those changes, as they require browsing
> > the git repository, which sometimes is not properly documented using
> > Vcs-*.
>
> I don't think it's the preferred method. I believe most of the project
> > I think that the preferred method (and widely accepted method) for
> > that is currently to use the 3.0 (quilt) format with DEP-3-documented
> > patches, on top of a tarball that contains the pristine upstream
> > source.
> >
> > The git packaging workflows that generate source packages using either
> > 1.0 native packages, or 1.0 non-native packages without patches, make it
> > harder to identify and review those changes, as they require browsing
> > the git repository, which sometimes is not properly documented using
> > Vcs-*.
>
> sees git histories are the preferred tool for achieving the goal you
> state.
>
> If we had only source packages for this purpose, then yes, 3.0 (quilt)
> plus DEP-3 would be preferred. But we have git, too, and indeed dgit.
> Repositories for packages contain both upstream history and Debian
> packaging history, and we have powerful git subcommands for extracting
> information. In many cases there is a good argument to be made that the
> git history is part of the preferred form of modification.
I think there are three different use cases to consider:
A. preferred form for regular contributions to the package (typically
by the package maintainer)
B. preferred form for occasional contributions to the package (typically
by an NMUer, or by the security team)
C. preferred form for reviewing the packaging and Debian-specific
changes.
I fully agree that the git repository is the preferred form for A.
However, for B and C, I think that our lingua franca is the source
package, and thus a source package that doesn't make it hard to
understand things such as Debian-specific patches. Of course that
could change if we were able to standardize on a git workflow (or
a small set of git workflows), but I don't see this happenning anytime
soon.
Lucas
Bastian Blank
Mar 29, 2022, 4:40:06 PM3/29/22
to
On Tue, Mar 15, 2022 at 04:29:17PM +0000, Ian Jackson wrote:
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
One additional point:
> a native format, but a non-native version number.
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
We currently have packages in the archive, which must be "3.0 (native)",
but are generated from other packages: all the secure boot signed
packages.
Example source package:
| Package: linux-signed-amd64
| Version: 5.17~rc8+1~exp1
is generated from binary package:
| Package: linux-image-amd64-signed-template
| Version: 5.17~rc8-1~exp1
Generating the source package needs to munge the version, just to
appease that version restriction. This also means, adding dependencies
on versions is difficult, as both versions sort differently. And bugs
are assigned to wrong versions, so version tracking does not work.
Regards,
Bastian
--
Kirk to Enterprise -- beam down yeoman Rand and a six-pack.
Matthew Vernon
May 10, 2022, 12:10:03 PM5/10/22
to
Hi,
I thought it might be useful to try and summarize where we are with this
bug, which hasn't see much recent activity (not least as there's a TC
meeting later...).
* Questions asked of the TC
The Committee was invited to issue advice on a number of points:
I - continued use of 1.0 native format
1) declare that there is nothing with with a package with a native
format but a non-native version number
2) request the dpkg maintainer relax the restriction of 3.0 native that
prevents using that format with a non-native version number
3) declare that the MBF on the topic shouldn't have been filed against
packages where the change is more complicated than simply change the
source format
II - continued use of 1.0-with-diff
4) declare that there are circumstances where use of 1.0-with-diff is
packages that are 1.0-with-diff (or at least not against all of them)
During the following discussion, TC has also been invited to come up
with policy on native packages and Debian revisions.
* Package formats
The TC have been told that:
1.0-without-diff is in some circumstances better than 3.0 (native),
because dpkg prohibits use of 3.0 native with a non-native version
number; were that restriction relaxed, 3.0 (native) could replace 1.0-native
1.0-with-diff has advantages over 3.0 (quilt) particularly with
git-based workflows, because in 3.0 (quilt) the diff is included inside
the source tree
3.0 (quilt) with single-debian-patch can represent some changes to the
source tree that 1.0-with-diff cannot
native format has the advantage over any quilt or diff format that it
can represent some changes to a source tree that patch/diff cannot
represent (e.g. changes to symlinks, which are changes you can make in git)
I don't believe any of these statements has been challenged.
* Discussion in the bug
Lucas (who filed the MBFs) has stated that they do not intend to make
them RC, nor reopen ones that the maintainers close. This may well make
3/5 relatively moot?
The issue of preferred form for modification has been raised (source
package in general, quilt stack, or VCS repo); Sam states that there is
consensus both that git workflows are best practice (especially where
upstream uses git), and that natives packages are sometimes an
appropriate tool to use. There is a wide range of git workflows, which
the occasional NMUer can avoid caring about by use of dgit(7).
There was also discussion of whether 1.0 formats were "niche" - they
represent 1.9% of packages in testing.
Russ argues that we should allow both native and non-native packages
(defined by whether there is a separate upstream release from the Debian
package) to use single-tarball source formats (and that the name 3.0
(native) is a bit confusing here); Felix instead contends that "native"
means instead that a package lacks a Debian patch, and we should stop
defining native or otherwise in terms of version numbers. There was some
further discussion of better terminology, but I don't think it went
anywhere conclusive.
Updates / corrections welcome :)
HTH,
Matthew
I thought it might be useful to try and summarize where we are with this
bug, which hasn't see much recent activity (not least as there's a TC
meeting later...).
* Questions asked of the TC
The Committee was invited to issue advice on a number of points:
I - continued use of 1.0 native format
1) declare that there is nothing with with a package with a native
format but a non-native version number
2) request the dpkg maintainer relax the restriction of 3.0 native that
prevents using that format with a non-native version number
3) declare that the MBF on the topic shouldn't have been filed against
packages where the change is more complicated than simply change the
source format
II - continued use of 1.0-with-diff
4) declare that there are circumstances where use of 1.0-with-diff is
the best tradeoff between different considerations
5) declare that the MBF on this topic shouldn't have been filed against
packages that are 1.0-with-diff (or at least not against all of them)
During the following discussion, TC has also been invited to come up
with policy on native packages and Debian revisions.
* Package formats
The TC have been told that:
1.0-without-diff is in some circumstances better than 3.0 (native),
because dpkg prohibits use of 3.0 native with a non-native version
number; were that restriction relaxed, 3.0 (native) could replace 1.0-native
1.0-with-diff has advantages over 3.0 (quilt) particularly with
git-based workflows, because in 3.0 (quilt) the diff is included inside
the source tree
3.0 (quilt) with single-debian-patch can represent some changes to the
source tree that 1.0-with-diff cannot
native format has the advantage over any quilt or diff format that it
can represent some changes to a source tree that patch/diff cannot
represent (e.g. changes to symlinks, which are changes you can make in git)
I don't believe any of these statements has been challenged.
* Discussion in the bug
Lucas (who filed the MBFs) has stated that they do not intend to make
them RC, nor reopen ones that the maintainers close. This may well make
3/5 relatively moot?
The issue of preferred form for modification has been raised (source
package in general, quilt stack, or VCS repo); Sam states that there is
consensus both that git workflows are best practice (especially where
upstream uses git), and that natives packages are sometimes an
appropriate tool to use. There is a wide range of git workflows, which
the occasional NMUer can avoid caring about by use of dgit(7).
There was also discussion of whether 1.0 formats were "niche" - they
represent 1.9% of packages in testing.
Russ argues that we should allow both native and non-native packages
(defined by whether there is a separate upstream release from the Debian
package) to use single-tarball source formats (and that the name 3.0
(native) is a bit confusing here); Felix instead contends that "native"
means instead that a package lacks a Debian patch, and we should stop
defining native or otherwise in terms of version numbers. There was some
further discussion of better terminology, but I don't think it went
anywhere conclusive.
Updates / corrections welcome :)
HTH,
Matthew
Sam Hartman
May 10, 2022, 12:50:03 PM5/10/22
to
>>>>> "Matthew" == Matthew Vernon <mat...@debian.org> writes:
Matthew> Hi, I thought it might be useful to try and summarize where
Matthew> we are with this bug, which hasn't see much recent activity
Matthew> (not least as there's a TC meeting later...).
I read your summary and agree it is accurate. Thank you.
Matthew> Hi, I thought it might be useful to try and summarize where
Matthew> we are with this bug, which hasn't see much recent activity
Matthew> (not least as there's a TC meeting later...).
I read your summary and agree it is accurate. Thank you.
Sean Whitton
May 10, 2022, 8:40:04 PM5/10/22
to
Hello,
At today's ctte meeting we considered whether we can start a vote on
this, but two committee members were missing, and someone else at the
meeting reported that they hadn't yet been able to spend enough time
thinking through the issue to be ready to vote.
We came up with the following plan. Below I've drafted a ballot. Once
each of those three individuals has let me know that they've had a
chance to catch up, I'll start a vote. The hope is that this can happen
well in advance of our next meeting. So, ctte members, if I don't
already know that you're caught up, please write to me once you are.
~~~~~
DRAFT
Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:
1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.
2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).
3. We suggest that the wontfix tag on #737634 be reconsidered.
4. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
5. We decline to comment on the recent source package format MBF.
Option A -- issue items 1--5
Option B -- issue items 1, 2, 3 and 5, but not 4
Option N -- none of the above.
END DRAFT
--
Sean Whitton
At today's ctte meeting we considered whether we can start a vote on
this, but two committee members were missing, and someone else at the
meeting reported that they hadn't yet been able to spend enough time
thinking through the issue to be ready to vote.
We came up with the following plan. Below I've drafted a ballot. Once
each of those three individuals has let me know that they've had a
chance to catch up, I'll start a vote. The hope is that this can happen
well in advance of our next meeting. So, ctte members, if I don't
already know that you're caught up, please write to me once you are.
~~~~~
DRAFT
Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:
1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.
2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).
3. We suggest that the wontfix tag on #737634 be reconsidered.
4. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
5. We decline to comment on the recent source package format MBF.
Option A -- issue items 1--5
Option B -- issue items 1, 2, 3 and 5, but not 4
Option N -- none of the above.
END DRAFT
--
Sean Whitton
Lucas Nussbaum
May 11, 2022, 5:10:03 AM5/11/22
to
Hi,
On 10/05/22 at 16:57 +0100, Matthew Vernon wrote:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
workflows:
- git-first workflows: packaging workflows that use git as the preferred
form for modification, and use the source package format as an opaque
output format
- git-using workflows: packaging workflows that use git for
collaboration and tracability, but aim at producing a source package
that is useful on its own (typically with a clean patch serie)
With this distinction made, I think that:
> Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git)
I think that:
- There is consensus that using a VCS, and Git in particular, for packaging
is a best practice
- git-using workflows are a best practice (based on their usage by the
vast majority of packages)
But I challenge that there is a consensus that git-first workflows are a
best practice. I think that they are a practice that is worth exploring
and experimenting on, but not yet widely adopted nor understood. But I
would be happy to be proven wrong (especially of based on facts).
Lucas
On 10/05/22 at 16:57 +0100, Matthew Vernon wrote:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
> The issue of preferred form for modification has been raised (source package
> in general, quilt stack, or VCS repo); Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git), and that natives packages are sometimes an appropriate tool to use.
> There is a wide range of git workflows, which the occasional NMUer can avoid
> caring about by use of dgit(7).
I think that the two above paragraphs mix two different categories of
> in general, quilt stack, or VCS repo); Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git), and that natives packages are sometimes an appropriate tool to use.
> There is a wide range of git workflows, which the occasional NMUer can avoid
> caring about by use of dgit(7).
workflows:
- git-first workflows: packaging workflows that use git as the preferred
form for modification, and use the source package format as an opaque
output format
- git-using workflows: packaging workflows that use git for
collaboration and tracability, but aim at producing a source package
that is useful on its own (typically with a clean patch serie)
With this distinction made, I think that:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
=> this really only applies to git-first workflows
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
> Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git)
- There is consensus that using a VCS, and Git in particular, for packaging
is a best practice
- git-using workflows are a best practice (based on their usage by the
vast majority of packages)
But I challenge that there is a consensus that git-first workflows are a
best practice. I think that they are a practice that is worth exploring
and experimenting on, but not yet widely adopted nor understood. But I
would be happy to be proven wrong (especially of based on facts).
Lucas
Lucas Nussbaum
May 11, 2022, 5:30:03 AM5/11/22
to
If it was possible to use 3.0 (native) with non-native revisions, would
there be remaining circumstances where 1.0-with-diff is the best choice?
If not, maybe the fact that this is the blocking issue should be made
explicit in (4)?
That would be a way to state: "either dpkg maints refuses to support 3.0
(native) with non-native revs, and 1.0-with-diff must not be considered
deprecated; or dpkg maints supports it, and it might be possible to
deprecate 1.0".
Lucas
Ian Jackson
May 11, 2022, 7:50:03 AM5/11/22
to
Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source package format with non-native version""):
If you have a package whose orig source code is large, and the delta
is representable with 1.0-with-diff (which is quite likely), then you
don't want to be reuploading the whole tarball each time. That's
wasteful of everyone's bandwidth and disk space.
So you want a representation that offers delta compression. That is
offered by the non-native formats. The non-native formats supported
by the archive are 1.0-with-diff and "3.0 (quilt)". The latter has
the problem with debian/patches/ living inside the source tree, which
is quite undesirable especially for "git-first workflows" (as the
draft text puts it).
> If not, maybe the fact that this is the blocking issue should be made
> explicit in (4)?
+ reuploading the whole source (including upstream) for each upload,
+ and also avoids having to maintain debian/patches/ inside the
+ package tree.
Or something.
> That would be a way to state: "either dpkg maints refuses to support 3.0
> (native) with non-native revs, and 1.0-with-diff must not be considered
> deprecated; or dpkg maints supports it, and it might be possible to
> deprecate 1.0".
I would love for there to be something like 3.0-with-git-diff. Indeed,
I filed this wishlist bug to ask if contribution would be welcome:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
but have not had any response.
The code in dpkg-source for 1.0-with-diff is quite crusty particularly
in respect of the implied behaviour wrt scanning your ".." for stuff.
The *format* of 1.0-with-diff is quite reasonable, but it lacks
support more kinds of delta. That could be done as an extension to
1.0-with-diff, but I doubt that would be a popular direction.
> If it was possible to use 3.0 (native) with non-native revisions, would
> there be remaining circumstances where 1.0-with-diff is the best choice?
Yes, unfortunately.
> there be remaining circumstances where 1.0-with-diff is the best choice?
If you have a package whose orig source code is large, and the delta
is representable with 1.0-with-diff (which is quite likely), then you
don't want to be reuploading the whole tarball each time. That's
wasteful of everyone's bandwidth and disk space.
So you want a representation that offers delta compression. That is
offered by the non-native formats. The non-native formats supported
by the archive are 1.0-with-diff and "3.0 (quilt)". The latter has
the problem with debian/patches/ living inside the source tree, which
is quite undesirable especially for "git-first workflows" (as the
draft text puts it).
> If not, maybe the fact that this is the blocking issue should be made
> explicit in (4)?
4. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
+ This is because there is currently no other source format which avoids
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
+ reuploading the whole source (including upstream) for each upload,
+ and also avoids having to maintain debian/patches/ inside the
+ package tree.
Or something.
> That would be a way to state: "either dpkg maints refuses to support 3.0
> (native) with non-native revs, and 1.0-with-diff must not be considered
> deprecated; or dpkg maints supports it, and it might be possible to
> deprecate 1.0".
I filed this wishlist bug to ask if contribution would be welcome:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
but have not had any response.
The code in dpkg-source for 1.0-with-diff is quite crusty particularly
in respect of the implied behaviour wrt scanning your ".." for stuff.
The *format* of 1.0-with-diff is quite reasonable, but it lacks
support more kinds of delta. That could be done as an extension to
1.0-with-diff, but I doubt that would be a popular direction.
Lucas Nussbaum
May 11, 2022, 8:10:03 AM5/11/22
to
Thanks for your answer.
On 11/05/22 at 12:38 +0100, Ian Jackson wrote:
> I would love for there to be something like 3.0-with-git-diff. Indeed,
> I filed this wishlist bug to ask if contribution would be welcome:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
> but have not had any response.
>
> The code in dpkg-source for 1.0-with-diff is quite crusty particularly
> in respect of the implied behaviour wrt scanning your ".." for stuff.
> The *format* of 1.0-with-diff is quite reasonable, but it lacks
> support more kinds of delta. That could be done as an extension to
> 1.0-with-diff, but I doubt that would be a popular direction.
Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
it be a good solution?
The main limitation I see is that it would not allow to represent
efficiently small changes to large text files (which a git-based diff
would allow).
I'm asking because if 3.0 (native) gets more generic by allowing
non-native revisions, it might be an easier sell to introduce
multi-tarballs support, than to introduce a completely different source
format.
Lucas
On 11/05/22 at 12:38 +0100, Ian Jackson wrote:
> I would love for there to be something like 3.0-with-git-diff. Indeed,
> I filed this wishlist bug to ask if contribution would be welcome:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
> but have not had any response.
>
> The code in dpkg-source for 1.0-with-diff is quite crusty particularly
> in respect of the implied behaviour wrt scanning your ".." for stuff.
> The *format* of 1.0-with-diff is quite reasonable, but it lacks
> support more kinds of delta. That could be done as an extension to
> 1.0-with-diff, but I doubt that would be a popular direction.
it be a good solution?
The main limitation I see is that it would not allow to represent
efficiently small changes to large text files (which a git-based diff
would allow).
I'm asking because if 3.0 (native) gets more generic by allowing
non-native revisions, it might be an easier sell to introduce
multi-tarballs support, than to introduce a completely different source
format.
Lucas
Ian Jackson
May 11, 2022, 12:40:03 PM5/11/22
to
Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source package format with non-native version""):
> Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> it be a good solution?
Oh, I hadn't thought of that.
> it be a good solution?
> The main limitation I see is that it would not allow to represent
> efficiently small changes to large text files (which a git-based diff
> would allow).
However, I think there are some other difficulties with this idea.
*Deletion* of files *is* important. Something would have to be done
to support that. (Tarball repacking is an abominable workflow which
we should only do when we must.)
It is important that packing and unpacking these things works roughly
the same way that things work right now for the diffish formats. Ie,
for a package with two tarballs, the first tarball would have to omit
the Debian revision from its filename (so that it needn't be
re-uploaded), and the second tarball would have to *contain* it.
dpkg-source -b would have to calculate the appropriate second tarball
as a diff from the first. (GNU tar has an incremental option that
could perhaps be used.)
I think, having followed this line of throught, the result looks quite
like a "3.0 (diff)" only the diff is in the form of an incremental
tarball rather than a textual patch file.
This could definitely work.
But I think that might not meet ftpmaster's review needs. AIUI
ftpmaster like to review the diff qua diff, and a tarball isn't so
straightforward. I had a similar idea to use an rsync batchfile as
the delta, which foundered on the same issue.
And I'm not sure that it will find better favour with dpkg upstream
than my "3.0 (git-diff)".
> I'm asking because if 3.0 (native) gets more generic by allowing
> non-native revisions, it might be an easier sell to introduce
> multi-tarballs support, than to introduce a completely different source
> format.
Right now, though, it's a bit hard to make progress without feedback
on what general direction would be most well received.
Lucas Nussbaum
May 11, 2022, 3:00:04 PM5/11/22
to
Example:
------------------------------>8
# create a first archive
mkdir t
echo foo > t/f1
echo bar > t/f2
echo baz > t/f3
tar --listed-increment=snapshot-file -czvvvf archive.tgz t
# remove a file, create an incremental archive
rm t/f2
tar --listed-increment=snapshot-file -czvvvf archive.1.tgz t
# remove everything
rm -rf snapshot-file t
# extract incremental archives
tar Gvvvxf archive.tgz
tar Gvvvxf archive.1.tgz
# listing of archive.1.tgz
tar Gvvvtf archive.1.tgz
------------------------------>8
This is implemented using the GNU-specific D entry type. According to
https://www.freebsd.org/cgi/man.cgi?query=tar&apropos=0&sektion=5&format=html :
D This indicates a directory entry. Unlike the POSIX-stan-
dard "5" typeflag, the header is followed by data records
listing the names of files in this directory. Each name
is preceded by an ASCII "Y" if the file is stored in this
archive or "N" if the file is not stored in this archive.
Each name is terminated with a null, and an extra null
marks the end of the name list. The purpose of this en-
try is to support incremental backups; a program restor-
ing from such an archive may wish to delete files on disk
that did not exist in the directory when the archive was
made.
Note that the "D" typeflag specifically violates POSIX,
which requires that unrecognized typeflags be restored as
normal files. In this case, restoring the "D" entry as a
file could interfere with subsequent creation of the
like-named directory.
> But I think that might not meet ftpmaster's review needs. AIUI
> ftpmaster like to review the diff qua diff, and a tarball isn't so
> straightforward. I had a similar idea to use an rsync batchfile as
> the delta, which foundered on the same issue.
a single tarball anyway...
Lucas
Ian Jackson
May 11, 2022, 3:10:03 PM5/11/22
to
ftpmaster (or, for that matter, the dpkg maintainers) will like.
Thanks for exploring the design space! What would be really good
would be to get agreement in principle from the key stakeholders...
Helmut Grohne
Jun 7, 2022, 1:50:03 AM6/7/22
to
Hallo,
On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote:
> DRAFT
>
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
I've given this some thought and feel uneasy about one item.
> 4. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
While I can agree with this item on a technical level, I think there is
more to it than that and I am wondering whether it sends the "right"
message.
Sometimes, things we do are technically possible and fill a niche well.
Yet, we decide that it is no longer reasonable to continue supporting
them and remove their support despite the feature being useful to some.
Quite clearly, there is a trade-off involved here. Continuing to support
1.0-with-diff comes with a cost that reduces uniformity inside the
archive. Evidently, this is what motivated Lucas to file the MBF
initially. My experience is that lack of uniformity is a significant
barrier to prospective contributors to Debian.
Exploring different technical approaches does have value as well, but I
think we've had sufficient time to consider the various advantages and
disadvantages of various source packages formats. On a whole, it seems
to me that that the number of packages benefiting from 1.0-with-diff is
relatively small.
What would you think about adding an alternative option 4?
4b. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package.
Given that the number of packages for which this is relevant is
fairly small, we recommend discontinuing use of 1.0-with-diff to
gain more uniformity.
Helmut
On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote:
> DRAFT
>
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 4. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
more to it than that and I am wondering whether it sends the "right"
message.
Sometimes, things we do are technically possible and fill a niche well.
Yet, we decide that it is no longer reasonable to continue supporting
them and remove their support despite the feature being useful to some.
Quite clearly, there is a trade-off involved here. Continuing to support
1.0-with-diff comes with a cost that reduces uniformity inside the
archive. Evidently, this is what motivated Lucas to file the MBF
initially. My experience is that lack of uniformity is a significant
barrier to prospective contributors to Debian.
Exploring different technical approaches does have value as well, but I
think we've had sufficient time to consider the various advantages and
disadvantages of various source packages formats. On a whole, it seems
to me that that the number of packages benefiting from 1.0-with-diff is
relatively small.
What would you think about adding an alternative option 4?
4b. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package.
Given that the number of packages for which this is relevant is
fairly small, we recommend discontinuing use of 1.0-with-diff to
gain more uniformity.
Helmut
Sean Whitton
Jun 7, 2022, 2:20:04 AM6/7/22
to
Hello,
On Tue 07 Jun 2022 at 07:43am +02, Helmut Grohne wrote:
> While I can agree with this item on a technical level, I think there is
> more to it than that and I am wondering whether it sends the "right"
> message.
>
> Sometimes, things we do are technically possible and fill a niche well.
> Yet, we decide that it is no longer reasonable to continue supporting
> them and remove their support despite the feature being useful to some.
> Quite clearly, there is a trade-off involved here. Continuing to support
> 1.0-with-diff comes with a cost that reduces uniformity inside the
> archive. Evidently, this is what motivated Lucas to file the MBF
> initially. My experience is that lack of uniformity is a significant
> barrier to prospective contributors to Debian.
I think this argument needs to be made more precise -- we should be
clearer about why this particular un-uniformity is bad. I don't think
the issue for new contributors is persuasive enough, as new contributors
can mostly ignore source packages. It's not like, e.g., debhelper
vs. cdbs. I haven't yet seen an argument that the lack of uniformity is
doing anyone's work any harm comparable to the harm done to things like
what Ian and Sam want to do.
> Exploring different technical approaches does have value as well, but I
> think we've had sufficient time to consider the various advantages and
> disadvantages of various source packages formats. On a whole, it seems
> to me that that the number of packages benefiting from 1.0-with-diff is
> relatively small.
I agree, it's not about the benefits of the source format, we do indeed
understand all the trade-offs by now. It's that certain ideas and
workflows *which are not really about source packages* are made
inconvenient or impossible if we remove this option. In other words, it
needs to be replaced before it can be deprecated.
> What would you think about adding an alternative option 4?
>
> 4b. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package.
> Given that the number of packages for which this is relevant is
> fairly small, we recommend discontinuing use of 1.0-with-diff to
> gain more uniformity.
Thanks for coming up with the text. I'd say that as uniformity is not
good in itself, it would be good to have more concrete reasons for
wanting uniformity in this case documented in this bug (not necessarily
in the resolution text) before we add it to the ballot.
--
Sean Whitton
On Tue 07 Jun 2022 at 07:43am +02, Helmut Grohne wrote:
> While I can agree with this item on a technical level, I think there is
> more to it than that and I am wondering whether it sends the "right"
> message.
>
> Sometimes, things we do are technically possible and fill a niche well.
> Yet, we decide that it is no longer reasonable to continue supporting
> them and remove their support despite the feature being useful to some.
> Quite clearly, there is a trade-off involved here. Continuing to support
> 1.0-with-diff comes with a cost that reduces uniformity inside the
> archive. Evidently, this is what motivated Lucas to file the MBF
> initially. My experience is that lack of uniformity is a significant
> barrier to prospective contributors to Debian.
clearer about why this particular un-uniformity is bad. I don't think
the issue for new contributors is persuasive enough, as new contributors
can mostly ignore source packages. It's not like, e.g., debhelper
vs. cdbs. I haven't yet seen an argument that the lack of uniformity is
doing anyone's work any harm comparable to the harm done to things like
what Ian and Sam want to do.
> Exploring different technical approaches does have value as well, but I
> think we've had sufficient time to consider the various advantages and
> disadvantages of various source packages formats. On a whole, it seems
> to me that that the number of packages benefiting from 1.0-with-diff is
> relatively small.
understand all the trade-offs by now. It's that certain ideas and
workflows *which are not really about source packages* are made
inconvenient or impossible if we remove this option. In other words, it
needs to be replaced before it can be deprecated.
> What would you think about adding an alternative option 4?
>
> 4b. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package.
> Given that the number of packages for which this is relevant is
> fairly small, we recommend discontinuing use of 1.0-with-diff to
> gain more uniformity.
good in itself, it would be good to have more concrete reasons for
wanting uniformity in this case documented in this bug (not necessarily
in the resolution text) before we add it to the ballot.
--
Sean Whitton
Lucas Nussbaum
Jun 7, 2022, 3:40:03 AM6/7/22
to
A middle ground between (4) and (4b) could be to discourage the use of
1.0-with-diff in circumstances where it is not justified. Something
like:
4c. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
including, but not limited to, git-first packaging workflows.
circumstances to gain more uniformity.
That opens the path to an archive where the only remaining 1.0 packages
are the ones where there's a reason to use 1.0. (as opposed to
currently, where we have a mix of packages using 1.0 for a good reason,
and packages using 1.0 because nobody cared to update them to modern
practices).
Lucas
Christoph Berg
Jun 7, 2022, 3:50:03 AM6/7/22
to
Re: Lucas Nussbaum
the 3.0 format to make it usable for the remaining cases where 1.0 is
still better today". Did anyone investigate if that would be feasible?
Christoph
> A middle ground between (4) and (4b) could be to discourage the use of
> 1.0-with-diff in circumstances where it is not justified. Something
> like:
>
> 4c. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
> However, we recommend discontinuing use of 1.0-with-diff in other
> circumstances to gain more uniformity.
>
> That opens the path to an archive where the only remaining 1.0 packages
> are the ones where there's a reason to use 1.0. (as opposed to
> currently, where we have a mix of packages using 1.0 for a good reason,
> and packages using 1.0 because nobody cared to update them to modern
> practices).
The bit I was missing is something like "we would welcome changes to
> 1.0-with-diff in circumstances where it is not justified. Something
> like:
>
> 4c. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
> However, we recommend discontinuing use of 1.0-with-diff in other
> circumstances to gain more uniformity.
>
> That opens the path to an archive where the only remaining 1.0 packages
> are the ones where there's a reason to use 1.0. (as opposed to
> currently, where we have a mix of packages using 1.0 for a good reason,
> and packages using 1.0 because nobody cared to update them to modern
> practices).
the 3.0 format to make it usable for the remaining cases where 1.0 is
still better today". Did anyone investigate if that would be feasible?
Christoph
Ian Jackson
Jun 7, 2022, 6:40:03 AM6/7/22
to
Helmut Grohne writes ("Re: Bug#1007717: Draft resolution for "Native source package format with non-native version""):
superiority) here is due entirely due to our inability to move forward
with a replacement for 1.0-with-diff that is actually superior for a
wider range of use cases.
I know that the TC has a history of favouring what looks like
"progress" over other factors (such as contributor happiness, software
diversity, and indeed inconvenient details).
In this case I would like to suggest that progress would be better
served by trying to unblock a better source format that (i) has some
kind of delta representation (ii) does not put a
needing-to-be-maintained copy of the delta metadata inside the working
tree.
There are several proposals for how to do that which are obviously
possible to implement. If the TC wants to unblock that, you could
look at them and pick one.
(And, I quextion whether .dsc format is the right place for Debian to
pursue uniformity. .dsc is a legacy format we are maintaining because
our git transition is stalled.)
> What would you think about adding an alternative option 4?
>
> 4b. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package.
> Given that the number of packages for which this is relevant is
> fairly small, we recommend discontinuing use of 1.0-with-diff to
> gain more uniformity.
It seems to me that the lack of uniformity (and indeed technical
>
> 4b. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package.
> Given that the number of packages for which this is relevant is
> fairly small, we recommend discontinuing use of 1.0-with-diff to
> gain more uniformity.
superiority) here is due entirely due to our inability to move forward
with a replacement for 1.0-with-diff that is actually superior for a
wider range of use cases.
I know that the TC has a history of favouring what looks like
"progress" over other factors (such as contributor happiness, software
diversity, and indeed inconvenient details).
In this case I would like to suggest that progress would be better
served by trying to unblock a better source format that (i) has some
kind of delta representation (ii) does not put a
needing-to-be-maintained copy of the delta metadata inside the working
tree.
There are several proposals for how to do that which are obviously
possible to implement. If the TC wants to unblock that, you could
look at them and pick one.
(And, I quextion whether .dsc format is the right place for Debian to
pursue uniformity. .dsc is a legacy format we are maintaining because
our git transition is stalled.)
Matthew Vernon
Jun 7, 2022, 6:50:03 AM6/7/22
to
On 07/06/2022 07:08, Sean Whitton wrote:
> I agree, it's not about the benefits of the source format, we do indeed
> understand all the trade-offs by now. It's that certain ideas and
> workflows *which are not really about source packages* are made
> inconvenient or impossible if we remove this option. In other words, it
> needs to be replaced before it can be deprecated.
Mmm. And I'd be pretty reluctant to talk about deprecation until the
> I agree, it's not about the benefits of the source format, we do indeed
> understand all the trade-offs by now. It's that certain ideas and
> workflows *which are not really about source packages* are made
> inconvenient or impossible if we remove this option. In other words, it
> needs to be replaced before it can be deprecated.
replacement is good to go.
>> What would you think about adding an alternative option 4?
>>
>> 4b. We believe that there are indeed circumstances in which
>> 1.0-with-diff is the best choice for a particular source package.
>> Given that the number of packages for which this is relevant is
>> fairly small, we recommend discontinuing use of 1.0-with-diff to
>> gain more uniformity.
>
> Thanks for coming up with the text. I'd say that as uniformity is not
> good in itself, it would be good to have more concrete reasons for
> wanting uniformity in this case documented in this bug (not necessarily
> in the resolution text) before we add it to the ballot.
persuasion that "more uniformity" here is a concrete benefit.
Regards,
Matthew
Ian Jackson
Jun 7, 2022, 7:50:09 AM6/7/22
to
Christoph Berg writes ("Re: Bug#1007717: Draft resolution for "Native source package format with non-native version""):
> Re: Lucas Nussbaum
technical level, and not even particularly difficult.
Contenders for the details that have been mentioned in this thread[1]
are 3.0-with-git-diff (#1007781) and Lucas's suggestion for
incremental tarballs in this conversation
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717#185).
That could certainly fit within "changes to 3.0" since 3.0 already
encompasses a very wide variety of formats.
The real diifficulty isn't technical. It's that it isn't worth
anyone's time *implementing* it because of the strong possibility that
its support and deployment would be blocked.
Perhaps TC would be willing to say something like this
We hope for the development of a version of the 3.0 format which is
good option, and we encourage its implementation. If the
implementation quality is good, we feel it should be supported
within Debian (subject to an appropriate transition plan).
I think 3.0-with-git-diff is the most promising candidate because it
fits into the existing ftpmaster workflow exactly as 1.0-with-diff
does now; this isn't so true of Lucas's incremental tarballs, and it
is even less true of my earlier 3.0-with-rsync-delta.
If the TC wants to give its blessing to one of the other format
proposals then that would be fine too from my point of view, but my
personal feeling is that it would be setting the TC up for a fight
with ftpmaster. From what I know of the ftpmaster workflow I think
even Lucas's incremental tarball proposal would be a retrograde step
for them.
> Re: Lucas Nussbaum
> > 4c. We believe that there are indeed circumstances in which
> > 1.0-with-diff is the best choice for a particular source package,
> > including, but not limited to, git-first packaging workflows.
> > However, we recommend discontinuing use of 1.0-with-diff in other
> > circumstances to gain more uniformity.
...
> > 1.0-with-diff is the best choice for a particular source package,
> > including, but not limited to, git-first packaging workflows.
> > However, we recommend discontinuing use of 1.0-with-diff in other
> > circumstances to gain more uniformity.
> The bit I was missing is something like "we would welcome changes to
> the 3.0 format to make it usable for the remaining cases where 1.0 is
> still better today". Did anyone investigate if that would be feasible?
A format that solves this problem well is entirely feasible on a
> the 3.0 format to make it usable for the remaining cases where 1.0 is
> still better today". Did anyone investigate if that would be feasible?
technical level, and not even particularly difficult.
Contenders for the details that have been mentioned in this thread[1]
are 3.0-with-git-diff (#1007781) and Lucas's suggestion for
incremental tarballs in this conversation
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717#185).
That could certainly fit within "changes to 3.0" since 3.0 already
encompasses a very wide variety of formats.
The real diifficulty isn't technical. It's that it isn't worth
anyone's time *implementing* it because of the strong possibility that
its support and deployment would be blocked.
Perhaps TC would be willing to say something like this
We hope for the development of a version of the 3.0 format which is
usable for the remaining cases where 1.0 is still better today.
The "3.0 with git diff" proposal in #1007781 seems to us to be a
good option, and we encourage its implementation. If the
implementation quality is good, we feel it should be supported
within Debian (subject to an appropriate transition plan).
I think 3.0-with-git-diff is the most promising candidate because it
fits into the existing ftpmaster workflow exactly as 1.0-with-diff
does now; this isn't so true of Lucas's incremental tarballs, and it
is even less true of my earlier 3.0-with-rsync-delta.
If the TC wants to give its blessing to one of the other format
proposals then that would be fine too from my point of view, but my
personal feeling is that it would be setting the TC up for a fight
with ftpmaster. From what I know of the ftpmaster workflow I think
even Lucas's incremental tarball proposal would be a retrograde step
for them.
Helmut Grohne
Jun 7, 2022, 5:00:04 PM6/7/22
to
Hi Sean,
On Mon, Jun 06, 2022 at 11:08:48PM -0700, Sean Whitton wrote:
> I think this argument needs to be made more precise -- we should be
> clearer about why this particular un-uniformity is bad. I don't think
> the issue for new contributors is persuasive enough, as new contributors
> can mostly ignore source packages. It's not like, e.g., debhelper
> vs. cdbs. I haven't yet seen an argument that the lack of uniformity is
> doing anyone's work any harm comparable to the harm done to things like
> what Ian and Sam want to do.
It seems to me that Ian et al works from the premise that source
packages are an export format and that git is the truth. In a sense,
that is correct as that's what most maintainers work with.
Unfortunately, packaging repositories have very diverse workflows, lack
discoverability and miss a simple trust root. A number of people have
tried to reconcile the various workflows, but that helps only so much.
On the other hand, source packages offer a very simple trust root and
uniform interface. If I am to modify an arbitrary package (with no prior
knowledge about it), I have some options to go about it.
I can use debcheckout. For a few packages, there is no repository
declared. Yet others point to non-existent servers. Still others point
to an obsolete repository that has been moved. After checking it out, I
have a git tree of something. It may come without upstream sources (e.g.
DHG) or with upstream sources. Patches may be applied or may be not. It
may be for the version I'm looking at or including unreleased changes or
pointing at some other suite. The representation of patches in git is
another story. The source repository may provide the ability to create
pull requests. Maybe the maintainer looks at them or maybe I'll have to
send a mail to the bts. I have no chance of figuring out this mess
without investing significant amount of time.
Then I can use dgit. It is way more uniform in a lot of aspects. Its
trust root resides with the CA cartel. The resulting tree may or may not
be representing the version I'm interested in. The history may be useful
or autogenerated for my checkout as initial checkin. The Debian
maintainer may be completely ignoring this representation. Most likely,
I won't be able to send a pull request.
And then, I can apt source the package. This is really simple and has an
easy to understand trust root. It also is reproducible. Unless using a
1.0 source format, debian/source/format tells me what kind of patch
system to expect and gladly there aren't too many options. I can
concentrate on the substance of my change without being distracted by
the packaging workflow details.
Please keep in mind that this is about trade-offs. It is a question of
how we value "package ownership". If we favour the strong ownership
approach that Debian used for a long time, then yes accommodating the
needs of maintainers is paramount. If we want to lessen the concept of
ownership, embrace drive-by contributions and decentralize maintenance,
then we need a stronger focus on uniformity. I suppose that my own
opinion on this matter is fairly obvious at this point.
Annoyingly enough, 3.0 (quilt) can be abused as well by deleting the
series file and managing patch application inside debian/rules. We do
have packages doing just that.
> I agree, it's not about the benefits of the source format, we do indeed
> understand all the trade-offs by now. It's that certain ideas and
> workflows *which are not really about source packages* are made
> inconvenient or impossible if we remove this option. In other words, it
> needs to be replaced before it can be deprecated.
I admit being somewhat ignorant towards workflows, because there are
just too many for me to be bothered to learn them all. In any case, I do
take issue with the premise that workflows need to continue to work.
We're deleting packages from unstable and stop supporting unique use
cases all the time. In most cases, we could continue supporting them for
longer, but we choose not to. I hope we all agree that there are too
many competing workflows. How would you go about reducing them to a sane
number?
> Thanks for coming up with the text. I'd say that as uniformity is not
> good in itself, it would be good to have more concrete reasons for
> wanting uniformity in this case documented in this bug (not necessarily
> in the resolution text) before we add it to the ballot.
You can rephrase it as reducing complexity if that helps. It's not the
one additional source package format that is too much. It's that we
continue using all the failed experiments while adding new ones and when
some Lucas comes around and tries to clean up the mess he gets referred
to us.
I have anecdotal evidence that people find Debian's processes too
complex. Unless you closely work withing a particular packaging team
(with unified processes), onboarding people into Debian takes very long
compared to other projects.
Helmut
On Mon, Jun 06, 2022 at 11:08:48PM -0700, Sean Whitton wrote:
> I think this argument needs to be made more precise -- we should be
> clearer about why this particular un-uniformity is bad. I don't think
> the issue for new contributors is persuasive enough, as new contributors
> can mostly ignore source packages. It's not like, e.g., debhelper
> vs. cdbs. I haven't yet seen an argument that the lack of uniformity is
> doing anyone's work any harm comparable to the harm done to things like
> what Ian and Sam want to do.
packages are an export format and that git is the truth. In a sense,
that is correct as that's what most maintainers work with.
Unfortunately, packaging repositories have very diverse workflows, lack
discoverability and miss a simple trust root. A number of people have
tried to reconcile the various workflows, but that helps only so much.
On the other hand, source packages offer a very simple trust root and
uniform interface. If I am to modify an arbitrary package (with no prior
knowledge about it), I have some options to go about it.
I can use debcheckout. For a few packages, there is no repository
declared. Yet others point to non-existent servers. Still others point
to an obsolete repository that has been moved. After checking it out, I
have a git tree of something. It may come without upstream sources (e.g.
DHG) or with upstream sources. Patches may be applied or may be not. It
may be for the version I'm looking at or including unreleased changes or
pointing at some other suite. The representation of patches in git is
another story. The source repository may provide the ability to create
pull requests. Maybe the maintainer looks at them or maybe I'll have to
send a mail to the bts. I have no chance of figuring out this mess
without investing significant amount of time.
Then I can use dgit. It is way more uniform in a lot of aspects. Its
trust root resides with the CA cartel. The resulting tree may or may not
be representing the version I'm interested in. The history may be useful
or autogenerated for my checkout as initial checkin. The Debian
maintainer may be completely ignoring this representation. Most likely,
I won't be able to send a pull request.
And then, I can apt source the package. This is really simple and has an
easy to understand trust root. It also is reproducible. Unless using a
1.0 source format, debian/source/format tells me what kind of patch
system to expect and gladly there aren't too many options. I can
concentrate on the substance of my change without being distracted by
the packaging workflow details.
Please keep in mind that this is about trade-offs. It is a question of
how we value "package ownership". If we favour the strong ownership
approach that Debian used for a long time, then yes accommodating the
needs of maintainers is paramount. If we want to lessen the concept of
ownership, embrace drive-by contributions and decentralize maintenance,
then we need a stronger focus on uniformity. I suppose that my own
opinion on this matter is fairly obvious at this point.
Annoyingly enough, 3.0 (quilt) can be abused as well by deleting the
series file and managing patch application inside debian/rules. We do
have packages doing just that.
> I agree, it's not about the benefits of the source format, we do indeed
> understand all the trade-offs by now. It's that certain ideas and
> workflows *which are not really about source packages* are made
> inconvenient or impossible if we remove this option. In other words, it
> needs to be replaced before it can be deprecated.
just too many for me to be bothered to learn them all. In any case, I do
take issue with the premise that workflows need to continue to work.
We're deleting packages from unstable and stop supporting unique use
cases all the time. In most cases, we could continue supporting them for
longer, but we choose not to. I hope we all agree that there are too
many competing workflows. How would you go about reducing them to a sane
number?
> Thanks for coming up with the text. I'd say that as uniformity is not
> good in itself, it would be good to have more concrete reasons for
> wanting uniformity in this case documented in this bug (not necessarily
> in the resolution text) before we add it to the ballot.
one additional source package format that is too much. It's that we
continue using all the failed experiments while adding new ones and when
some Lucas comes around and tries to clean up the mess he gets referred
to us.
I have anecdotal evidence that people find Debian's processes too
complex. Unless you closely work withing a particular packaging team
(with unified processes), onboarding people into Debian takes very long
compared to other projects.
Helmut
Sean Whitton
Jun 8, 2022, 1:40:03 AM6/8/22
to
Hello,
On Tue 10 May 2022 at 05:29pm -07, Sean Whitton wrote:
> At today's ctte meeting we considered whether we can start a vote on
> this, but two committee members were missing, and someone else at the
> meeting reported that they hadn't yet been able to spend enough time
> thinking through the issue to be ready to vote.
>
> We came up with the following plan. Below I've drafted a ballot. Once
> each of those three individuals has let me know that they've had a
> chance to catch up, I'll start a vote. The hope is that this can happen
> well in advance of our next meeting. So, ctte members, if I don't
> already know that you're caught up, please write to me once you are.
Unfortunately, people haven't yet indicated they're caught up.
Here's an updated ballot in light of our upcoming meeting. I've left
space to add a 4b, if, when our current discussion is concluded, someone
would like that in addition to 4c.
~~~~~
DRAFT
Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:
1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.
2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).
3. We suggest that the wontfix tag on #737634 be reconsidered.
4a. We believe that there are indeed circumstances in which
such that avoid both (i) uploading the whole source, including
upstream, for every upload; and (ii) having to maintain
debian/patches/ inside the package tree.
4c. We believe that there are indeed circumstances in which
This is because ... [second paragraph as in 4a].
5. We decline to comment on the recent source package format MBF.
Option A -- issue items 1-3, 4a and 5
Option C -- issue items 1-3, 4c and 5
Option X -- issue only items 1, 2, 3 and 5
On Tue 10 May 2022 at 05:29pm -07, Sean Whitton wrote:
> At today's ctte meeting we considered whether we can start a vote on
> this, but two committee members were missing, and someone else at the
> meeting reported that they hadn't yet been able to spend enough time
> thinking through the issue to be ready to vote.
>
> We came up with the following plan. Below I've drafted a ballot. Once
> each of those three individuals has let me know that they've had a
> chance to catch up, I'll start a vote. The hope is that this can happen
> well in advance of our next meeting. So, ctte members, if I don't
> already know that you're caught up, please write to me once you are.
Here's an updated ballot in light of our upcoming meeting. I've left
space to add a 4b, if, when our current discussion is concluded, someone
would like that in addition to 4c.
~~~~~
DRAFT
Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:
1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.
2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).
3. We suggest that the wontfix tag on #737634 be reconsidered.
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
This is because there is currently no other source format which is
including, but not limited to, git-first packaging workflows.
such that avoid both (i) uploading the whole source, including
upstream, for every upload; and (ii) having to maintain
debian/patches/ inside the package tree.
4c. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
circumstances, to simplify the contents of the archive.
This is because ... [second paragraph as in 4a].
5. We decline to comment on the recent source package format MBF.
Option C -- issue items 1-3, 4c and 5
Option X -- issue only items 1, 2, 3 and 5
Julian Andres Klode
Jun 8, 2022, 6:10:04 AM6/8/22
to
On Tue, Jun 07, 2022 at 08:19:29PM +0200, Helmut Grohne wrote:
> Please keep in mind that this is about trade-offs. It is a question of
> how we value "package ownership". If we favour the strong ownership
> approach that Debian used for a long time, then yes accommodating the
> needs of maintainers is paramount. If we want to lessen the concept of
> ownership, embrace drive-by contributions and decentralize maintenance,
> then we need a stronger focus on uniformity. I suppose that my own
> opinion on this matter is fairly obvious at this point.
This is also a significant issue for downstreams. With my Ubuntu hat
> Please keep in mind that this is about trade-offs. It is a question of
> how we value "package ownership". If we favour the strong ownership
> approach that Debian used for a long time, then yes accommodating the
> needs of maintainers is paramount. If we want to lessen the concept of
> ownership, embrace drive-by contributions and decentralize maintenance,
> then we need a stronger focus on uniformity. I suppose that my own
> opinion on this matter is fairly obvious at this point.
on, if I have to touch packages downstream, I loathe it everytime I
get a non-descript blob of all the changes.
I suspect this is the same for other downstream distributions that
want to modify packages. We cannot cater to everyone's individual
packaging repository approach, and downstream repositories if they
exist are separate anyhow.
Using 1.0 instead of 3.0 (quilt) is just being a hostile upstream,
like Red Hat is with dumping all their kernel patches together.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Helmut Grohne
Jun 8, 2022, 3:10:04 PM6/8/22
to
Hi Sean,
On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote:
> I disagree with you that this is primarily about package ownership, and
> I think that we agree on more than you realise we do :)
Hmm. It's not that obvious. While it would be possible to remove the
choice of workflow from strong package ownership, the way we practice
package ownership presently grants that freedom. Therefore I think they
still are closely related.
> The git-first people are not making a trade-off between the maintainer's
> convenience and the convenience of others who want to work with the
> package. The most important reason for wanting both (i) git-first
> workflows and (ii) uploads done with dgit, is to make it easier for
> people other than the maintainer to work with the package. So, your
> priorities are quite in agreement with those of Ian, Sam, Russ and I.
I find it interesting that you seem to equate git-first with dgit. My
mental model separated those concepts and considered git-first workflows
on salsa as well. And once you equate them, you can derive a lot of
conclusions. In my previous mail, I stated that dgit provides the sort
of uniformity I was looking for quite many aspects. I'm less sure that
all git-first users are dgit users though.
> In other words, I would like to make weaker package ownership more
> possible, in a project with Debian's history, by improving our tools for
> dealing with packages for which you're not primary maintainer.
I do see how this is a dgit goal. It just seems to me that dgit bolts a
secondary workflow onto packages that maintainers are free to ignore
entirely. Some choose to use that dgit workflow exclusively and others
don't. In a sense, the problem with dgit is that it leaves too much
freedom to maintainers (and in a project like Debian, it really has to
do exactly that or it would run into straight opposition).
> What we disagree about is the extent to which the current tooling
> amounts to a failed experiment, such that we should give up on it and
> fall back to 'apt-get source'. Many people strongly prefer 'dgit clone'
> to 'apt-get source' already, and the number of people switching to
> upload with 'dgit [--gbp] push-source' is steadily rising. Against this
> backdrop, some of us are interested in git-first workflows for reducing
> the distance between the output of 'debcheckout' and 'dgit clone'.
Indeed, dgit kinda faces a chicken & egg problem and it seems that it is
quite good at solving it: The usefulness of dgit grows with its
adoption. I have looked into replacing my apt source workflow with dgit
clone a number of times already and will continue trying.
> It's completely reasonable that you're more sceptical about the
> prospects of solving the outstanding issues in this programme than
> others are, but surely we can agree that this is an ongoing piece of
> work rather than something we're sure we can reject? And if keeping an
> old source package format around is needed for that work to continue,
> then that's a compelling reason to keep it around.
I think I take more issue with non-dgit git-first workflows than with
dgit ones, because dgit is so well documented and is a workflow that is
already shared by a noticeable fraction of the archive.
What is not entirely clear to me is why dgit requires the 1.0-with-diff
format features. It seems to me that it quite happily deals with a
number of 3.0 (quilt) packages already. I suppose that you'll now
explain to me how some git trees are not representable as 3.0 (quilt)
packages, but do those exist in practice or are those mostly
pathological?
> > How would you go about reducing them to a sane number?
>
> The goal is to attack this problem on two fronts:
>
> 1. reduce the need for uniformity by making it possible for people to
> get their cross-archive work done using 'dgit clone'
I've seen this argument multiple times already and indeed dgit solves
part of the uniformity issues. However, dgit history often lacks
maintainer history (and in that way is little better than apt source)
and it also lacks a collaboration feature that would save me from
sending a .debdiff to the bts. Possibly, such a collaboration feature is
out-of-scope for dgit, but then maybe it is not the kind of tool solving
the problem of streamlining cross-archive work.
Either way, my understanding is that unless maintainers switch to using
dgit primarily, we just gain a secondary workflow here.
> 2. develop git-first workflows that solve all the existing usecases.
Can i rephrase that as follows? Implement so many features into dgit
that its workflow covers the needs of existing workflows and hope for
maintainers to migrate to dgit.
It feels a bit like https://xkcd.com/927/ (14 competing standards ->
15). On the other hand, dgit is remarkably successful already.
I had hoped that we could kinda trim the available workflows eventually.
It seems like you want to let them all die slowly and concurrently.
> > You can rephrase it as reducing complexity if that helps. It's not the
> > one additional source package format that is too much. It's that we
> > continue using all the failed experiments while adding new ones and when
> > some Lucas comes around and tries to clean up the mess he gets referred
> > to us.
>
> As I said, I don't think it's fair to characterise the git-first work as
> a failed experiment. It's ongoing work. And the source package format
> is just a way to keep it going, at the present moment.
That's a bold statement. I don't think there is "the git-first work".
Instead there is lots of concurrent git-first workflows that are all
somewhat similar and yet subtly different. Those subtle differences is
what I would like to get rid of.
Now we've turned a discussion about source package formats into a
discussion about workflows and git. So when I reason about uniformity, I
effectively want those idiosyncratic workflows to go away. If dgit
requires 1.0-with-diff for now, then maybe we could phrase it as an
exception that is specific to dgit and limited until a better solution
(such as the format proposed by Ian) is mature. If there are more
git-first workflows beyond dgit that we want to support, maybe we can
require declaring a working Vcs-Git for 1.0-with-diff uploads?
Helmut
On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote:
> I disagree with you that this is primarily about package ownership, and
> I think that we agree on more than you realise we do :)
Hmm. It's not that obvious. While it would be possible to remove the
choice of workflow from strong package ownership, the way we practice
package ownership presently grants that freedom. Therefore I think they
still are closely related.
> The git-first people are not making a trade-off between the maintainer's
> convenience and the convenience of others who want to work with the
> package. The most important reason for wanting both (i) git-first
> workflows and (ii) uploads done with dgit, is to make it easier for
> people other than the maintainer to work with the package. So, your
> priorities are quite in agreement with those of Ian, Sam, Russ and I.
I find it interesting that you seem to equate git-first with dgit. My
mental model separated those concepts and considered git-first workflows
on salsa as well. And once you equate them, you can derive a lot of
conclusions. In my previous mail, I stated that dgit provides the sort
of uniformity I was looking for quite many aspects. I'm less sure that
all git-first users are dgit users though.
> In other words, I would like to make weaker package ownership more
> possible, in a project with Debian's history, by improving our tools for
> dealing with packages for which you're not primary maintainer.
I do see how this is a dgit goal. It just seems to me that dgit bolts a
secondary workflow onto packages that maintainers are free to ignore
entirely. Some choose to use that dgit workflow exclusively and others
don't. In a sense, the problem with dgit is that it leaves too much
freedom to maintainers (and in a project like Debian, it really has to
do exactly that or it would run into straight opposition).
> What we disagree about is the extent to which the current tooling
> amounts to a failed experiment, such that we should give up on it and
> fall back to 'apt-get source'. Many people strongly prefer 'dgit clone'
> to 'apt-get source' already, and the number of people switching to
> upload with 'dgit [--gbp] push-source' is steadily rising. Against this
> backdrop, some of us are interested in git-first workflows for reducing
> the distance between the output of 'debcheckout' and 'dgit clone'.
Indeed, dgit kinda faces a chicken & egg problem and it seems that it is
quite good at solving it: The usefulness of dgit grows with its
adoption. I have looked into replacing my apt source workflow with dgit
clone a number of times already and will continue trying.
> It's completely reasonable that you're more sceptical about the
> prospects of solving the outstanding issues in this programme than
> others are, but surely we can agree that this is an ongoing piece of
> work rather than something we're sure we can reject? And if keeping an
> old source package format around is needed for that work to continue,
> then that's a compelling reason to keep it around.
I think I take more issue with non-dgit git-first workflows than with
dgit ones, because dgit is so well documented and is a workflow that is
already shared by a noticeable fraction of the archive.
What is not entirely clear to me is why dgit requires the 1.0-with-diff
format features. It seems to me that it quite happily deals with a
number of 3.0 (quilt) packages already. I suppose that you'll now
explain to me how some git trees are not representable as 3.0 (quilt)
packages, but do those exist in practice or are those mostly
pathological?
> > How would you go about reducing them to a sane number?
>
>
> 1. reduce the need for uniformity by making it possible for people to
> get their cross-archive work done using 'dgit clone'
I've seen this argument multiple times already and indeed dgit solves
part of the uniformity issues. However, dgit history often lacks
maintainer history (and in that way is little better than apt source)
and it also lacks a collaboration feature that would save me from
sending a .debdiff to the bts. Possibly, such a collaboration feature is
out-of-scope for dgit, but then maybe it is not the kind of tool solving
the problem of streamlining cross-archive work.
Either way, my understanding is that unless maintainers switch to using
dgit primarily, we just gain a secondary workflow here.
> 2. develop git-first workflows that solve all the existing usecases.
Can i rephrase that as follows? Implement so many features into dgit
that its workflow covers the needs of existing workflows and hope for
maintainers to migrate to dgit.
It feels a bit like https://xkcd.com/927/ (14 competing standards ->
15). On the other hand, dgit is remarkably successful already.
I had hoped that we could kinda trim the available workflows eventually.
It seems like you want to let them all die slowly and concurrently.
> > You can rephrase it as reducing complexity if that helps. It's not the
> > one additional source package format that is too much. It's that we
> > continue using all the failed experiments while adding new ones and when
> > some Lucas comes around and tries to clean up the mess he gets referred
> > to us.
>
> a failed experiment. It's ongoing work. And the source package format
> is just a way to keep it going, at the present moment.
That's a bold statement. I don't think there is "the git-first work".
Instead there is lots of concurrent git-first workflows that are all
somewhat similar and yet subtly different. Those subtle differences is
what I would like to get rid of.
Now we've turned a discussion about source package formats into a
discussion about workflows and git. So when I reason about uniformity, I
effectively want those idiosyncratic workflows to go away. If dgit
requires 1.0-with-diff for now, then maybe we could phrase it as an
exception that is specific to dgit and limited until a better solution
(such as the format proposed by Ian) is mature. If there are more
git-first workflows beyond dgit that we want to support, maybe we can
require declaring a working Vcs-Git for 1.0-with-diff uploads?
Helmut
Lucas Nussbaum
Jun 8, 2022, 4:40:03 PM6/8/22
to
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> I think I take more issue with non-dgit git-first workflows than with
> dgit ones, because dgit is so well documented and is a workflow that is
> already shared by a noticeable fraction of the archive.
I'm curious: how do you measure dgit usage?
> I think I take more issue with non-dgit git-first workflows than with
> dgit ones, because dgit is so well documented and is a workflow that is
> already shared by a noticeable fraction of the archive.
You cannot just look at the list of repositories at
https://browse.dgit.debian.org/, since that just says that at some point
in the past, someone used dgit to work on that package, right?
For example, the keepass2 package has a repo there, but it is completely
outdated compared to what is in unstable.
Lucas
Lucas Nussbaum
Jun 8, 2022, 4:40:04 PM6/8/22
to
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> Now we've turned a discussion about source package formats into a
> discussion about workflows and git. So when I reason about uniformity, I
> effectively want those idiosyncratic workflows to go away. If dgit
> requires 1.0-with-diff for now, then maybe we could phrase it as an
> exception that is specific to dgit and limited until a better solution
> (such as the format proposed by Ian) is mature. If there are more
> git-first workflows beyond dgit that we want to support, maybe we can
> require declaring a working Vcs-Git for 1.0-with-diff uploads?
I think that the workflow used by the Debian X team is such a git-first
> discussion about workflows and git. So when I reason about uniformity, I
> effectively want those idiosyncratic workflows to go away. If dgit
> requires 1.0-with-diff for now, then maybe we could phrase it as an
> exception that is specific to dgit and limited until a better solution
> (such as the format proposed by Ian) is mature. If there are more
> git-first workflows beyond dgit that we want to support, maybe we can
> require declaring a working Vcs-Git for 1.0-with-diff uploads?
workflow that is not using dgit. That workflow combines Debian-specific
patches managed by quilt, and commits cherry-picked from upstream
directly applied to the source in git (outside of quilt).
See <YjBujid4Z4XYNobE@jcristau-z4>
There are 89 packages maintained by Debian X among the 607 packages in
testing still using 1.0.
Lucas
Helmut Grohne
Jun 15, 2022, 1:40:03 AM6/15/22
to
Hi,
On Tue, Jun 07, 2022 at 10:31:18PM -0700, Sean Whitton wrote:
> Here's an updated ballot in light of our upcoming meeting. I've left
> space to add a 4b, if, when our current discussion is concluded, someone
> would like that in addition to 4c.
After the meeting, Simon, Sean and myself further discussed aspect 4
without reaching conensus. I'll try to summarize the views expressed
here.
Simon looked at how other distributions approach patches and figured
that basically everyone else uses the patches-unapplied model. Going
patches-unapplied has the benefit of not imposing a particular workflow
onto your git repository. It can be gbp-pq, saving the output of git
format-patch or an email patch, or even writing diff syntax manually. We
also observed that a significant portion of Debian uses the
patches-unapplied model, including but not limited to Gnome, Haskell, Perl,
Python, systemd, much of pkg-games and utopia/freedesktop. It is fair to
say that dgit is an outlier here in choosing patches-applied as a model.
The 3.0 (quilt) format was specifically designed for the
patches-unapplied model (which is also why it is not that a good fit for
dgit). And for that reason, people who prefer patches-unapplied see
little reason to keep using 1.0 source formats. For 1.0-native, we
already figured that 3.0 (native) would be better once lifting the
revision restriction. For 1.0-with-diff, there are two basic models. In
one model, you patch everything directly and most likely manage your
diff in some VCS (e.g. git). In this model, there typically is no
debian/patches or other kind of patch management system in the source
package. The other model restricts itself to only adding files below
debian/ and then using debian/rules to actually apply patches during
build. This latter model is fairly annoying, because there are so many
different ways of doing it (i.e. we lack consistency there).
So what I'd like to ensure is that any resolution we do here is clear
about discontinuing the use of 1.0-with-diff together with a patch
system to be applied during package build. We've explored that model in
depth and settled on 3.0 (quilt) as the superior solution. There is no
need to explore it any further (and as demonstrated by curl, gcc and
glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the
only reasonable use of 1.0-with-diff is where you manage your diff
externally rather than during package build.
> 4a. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
>
> This is because there is currently no other source format which is
> such that avoid both (i) uploading the whole source, including
> upstream, for every upload; and (ii) having to maintain
> debian/patches/ inside the package tree.
>
> 4c. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
> However, we recommend discontinuing use of 1.0-with-diff in other
> circumstances, to simplify the contents of the archive.
>
> This is because ... [second paragraph as in 4a].
For the reasons above, I do think we need another variant of 4. Both of
these leave room for using 1.0-with-diff in combination with a patch
system. Beyond that, we're still giving advice and our advice is a
non-binding recommendation. So going a bit less vague seems warranted to
me. Sean cautioned that we should not deny future developments. I don't
think any future developments should use 1.0-with-diff, so trimming the
possible use cases for 1.0-with-diff to a minimum that explicitly
excludes use with a build-time patch system is what I think we do.
Some people have been asking me why I think consistency is important. I
think the most useful explanation is practical experience here. I
routinely do archive-wide work and I've basically reached a point where
I do no longer send patches for 1.0 source packages, because it simply
takes too much time to figure out their workflows unless fixing that
particular issue is relatively important to me. So yes, 1.0 does present
a practical barrier to contribution.
Helmut
On Tue, Jun 07, 2022 at 10:31:18PM -0700, Sean Whitton wrote:
> Here's an updated ballot in light of our upcoming meeting. I've left
> space to add a 4b, if, when our current discussion is concluded, someone
> would like that in addition to 4c.
without reaching conensus. I'll try to summarize the views expressed
here.
Simon looked at how other distributions approach patches and figured
that basically everyone else uses the patches-unapplied model. Going
patches-unapplied has the benefit of not imposing a particular workflow
onto your git repository. It can be gbp-pq, saving the output of git
format-patch or an email patch, or even writing diff syntax manually. We
also observed that a significant portion of Debian uses the
patches-unapplied model, including but not limited to Gnome, Haskell, Perl,
Python, systemd, much of pkg-games and utopia/freedesktop. It is fair to
say that dgit is an outlier here in choosing patches-applied as a model.
The 3.0 (quilt) format was specifically designed for the
patches-unapplied model (which is also why it is not that a good fit for
dgit). And for that reason, people who prefer patches-unapplied see
little reason to keep using 1.0 source formats. For 1.0-native, we
already figured that 3.0 (native) would be better once lifting the
revision restriction. For 1.0-with-diff, there are two basic models. In
one model, you patch everything directly and most likely manage your
diff in some VCS (e.g. git). In this model, there typically is no
debian/patches or other kind of patch management system in the source
package. The other model restricts itself to only adding files below
debian/ and then using debian/rules to actually apply patches during
build. This latter model is fairly annoying, because there are so many
different ways of doing it (i.e. we lack consistency there).
So what I'd like to ensure is that any resolution we do here is clear
about discontinuing the use of 1.0-with-diff together with a patch
system to be applied during package build. We've explored that model in
depth and settled on 3.0 (quilt) as the superior solution. There is no
need to explore it any further (and as demonstrated by curl, gcc and
glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the
only reasonable use of 1.0-with-diff is where you manage your diff
externally rather than during package build.
> 4a. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
>
> This is because there is currently no other source format which is
> such that avoid both (i) uploading the whole source, including
> upstream, for every upload; and (ii) having to maintain
> debian/patches/ inside the package tree.
>
> 4c. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package,
> including, but not limited to, git-first packaging workflows.
> However, we recommend discontinuing use of 1.0-with-diff in other
> circumstances, to simplify the contents of the archive.
>
> This is because ... [second paragraph as in 4a].
these leave room for using 1.0-with-diff in combination with a patch
system. Beyond that, we're still giving advice and our advice is a
non-binding recommendation. So going a bit less vague seems warranted to
me. Sean cautioned that we should not deny future developments. I don't
think any future developments should use 1.0-with-diff, so trimming the
possible use cases for 1.0-with-diff to a minimum that explicitly
excludes use with a build-time patch system is what I think we do.
Some people have been asking me why I think consistency is important. I
think the most useful explanation is practical experience here. I
routinely do archive-wide work and I've basically reached a point where
I do no longer send patches for 1.0 source packages, because it simply
takes too much time to figure out their workflows unless fixing that
particular issue is relatively important to me. So yes, 1.0 does present
a practical barrier to contribution.
Helmut
Christoph Berg
Jun 15, 2022, 4:40:03 AM6/15/22
to
Re: Helmut Grohne
variant that summarizes it? I admit I'm lost between all the details
and would like a spot to go to, and then look at the alternatives from
that viewpoint (or vote for that spot rightaway).
Christoph
> For the reasons above, I do think we need another variant of 4.
Your view makes a lot of sense. Would you think you could draft a "4"
variant that summarizes it? I admit I'm lost between all the details
and would like a spot to go to, and then look at the alternatives from
that viewpoint (or vote for that spot rightaway).
Christoph
Ian Jackson
Jun 15, 2022, 6:20:04 AM6/15/22
to
Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
are still using tarballs-and-patches.
However, for anyone else - particularly, anyone not from a distro
background, it is a serious problem. I wrote about this on my blog:
Get source to Debian packages only via dgit; "official" git links
are beartraps
https://diziet.dreamwidth.org/9556.html
As I say in the blog post, the danger of a user using "official" git
from Salsa, and building a package without the Debian patches applied,
is not theoretical. One of my friends - an expert programmer (and
expert user of git) - did precisely that, prompting my post.
(IME most Debian insiders severly underestimate the scale of the
problems faced by a random user who is already a programmer and just
wants to make some change to a package.)
Happily, it is possible to reconcile the disagreement about applied vs
unapplied by automatically converting. dgit, and Sean and my
tag2upload system, do precisely this, in the "forward" direction,
which is the most important one.
I think it would also be possible to automatically do the reverse
conversion. This could allow a gitlab MR style workflow for a
contributor who started with a patches-applied "naive external
contributor" branch.
The reverse conversion of a user's contribution is of course already
easy to do manually: if your contributor sends you a branch based on
the dgit view[1], you can simply rebase their work onto your gbp pq
branch.
[1] This is difficult for the user right now since the dgit server is
not "forge" and doesn't invite the user to do this. Instead, the user
will probably email patches.
Ian.
> Simon looked at how other distributions approach patches and figured
> that basically everyone else uses the patches-unapplied model.
patches-unapplied is a good fit for distro experts in distros which
> that basically everyone else uses the patches-unapplied model.
are still using tarballs-and-patches.
However, for anyone else - particularly, anyone not from a distro
background, it is a serious problem. I wrote about this on my blog:
Get source to Debian packages only via dgit; "official" git links
are beartraps
https://diziet.dreamwidth.org/9556.html
As I say in the blog post, the danger of a user using "official" git
from Salsa, and building a package without the Debian patches applied,
is not theoretical. One of my friends - an expert programmer (and
expert user of git) - did precisely that, prompting my post.
(IME most Debian insiders severly underestimate the scale of the
problems faced by a random user who is already a programmer and just
wants to make some change to a package.)
Happily, it is possible to reconcile the disagreement about applied vs
unapplied by automatically converting. dgit, and Sean and my
tag2upload system, do precisely this, in the "forward" direction,
which is the most important one.
I think it would also be possible to automatically do the reverse
conversion. This could allow a gitlab MR style workflow for a
contributor who started with a patches-applied "naive external
contributor" branch.
The reverse conversion of a user's contribution is of course already
easy to do manually: if your contributor sends you a branch based on
the dgit view[1], you can simply rebase their work onto your gbp pq
branch.
[1] This is difficult for the user right now since the dgit server is
not "forge" and doesn't invite the user to do this. Instead, the user
will probably email patches.
Ian.
Lucas Nussbaum
Jun 15, 2022, 10:10:04 AM6/15/22
to
Hi,
On 15/06/22 at 07:32 +0200, Helmut Grohne wrote:
> The other model restricts itself to only adding files below
> debian/ and then using debian/rules to actually apply patches during
> build. This latter model is fairly annoying, because there are so many
> different ways of doing it (i.e. we lack consistency there).
If you look at Debian 'testing' only, I think that the only remaining
way to do that is 1.0 + quilt (packages that were using dpatch have all
been converted or removed from testing).
> So what I'd like to ensure is that any resolution we do here is clear
> about discontinuing the use of 1.0-with-diff together with a patch
> system to be applied during package build. We've explored that model in
> depth and settled on 3.0 (quilt) as the superior solution. There is no
> need to explore it any further (and as demonstrated by curl, gcc and
> glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the
> only reasonable use of 1.0-with-diff is where you manage your diff
> externally rather than during package build.
According to https://udd.debian.org/~lucas/format10.cgi (which is based
on what lintian knows about the archive), there are 114 packages using
1.0 with quilt. However, 67 of those are maintained by the Debian X
team. If you plan to discontinue 1.0+patch-system in the context of
this bug, it would probably be a good idea to have a discussion with
them to better understand their use case.
I personally think that it would be enough for this bug to issue a clear
statement that we want to move away from 1.0 unless there's a good
reason, on a per-package basis, not to. That would create a mandate to
work on surveying the remaining packages and identifying the remaining
use cases. That would also allow motivated volunteers to work on
migrating the remaining packages when there's no reason to stay with
1.0, using the NMU procedure if needed.
Lucas
On 15/06/22 at 07:32 +0200, Helmut Grohne wrote:
> The other model restricts itself to only adding files below
> debian/ and then using debian/rules to actually apply patches during
> build. This latter model is fairly annoying, because there are so many
> different ways of doing it (i.e. we lack consistency there).
way to do that is 1.0 + quilt (packages that were using dpatch have all
been converted or removed from testing).
> So what I'd like to ensure is that any resolution we do here is clear
> about discontinuing the use of 1.0-with-diff together with a patch
> system to be applied during package build. We've explored that model in
> depth and settled on 3.0 (quilt) as the superior solution. There is no
> need to explore it any further (and as demonstrated by curl, gcc and
> glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the
> only reasonable use of 1.0-with-diff is where you manage your diff
> externally rather than during package build.
on what lintian knows about the archive), there are 114 packages using
1.0 with quilt. However, 67 of those are maintained by the Debian X
team. If you plan to discontinue 1.0+patch-system in the context of
this bug, it would probably be a good idea to have a discussion with
them to better understand their use case.
I personally think that it would be enough for this bug to issue a clear
statement that we want to move away from 1.0 unless there's a good
reason, on a per-package basis, not to. That would create a mandate to
work on surveying the remaining packages and identifying the remaining
use cases. That would also allow motivated volunteers to work on
migrating the remaining packages when there's no reason to stay with
1.0, using the NMU procedure if needed.
Lucas
Helmut Grohne
Jun 16, 2022, 3:00:04 AM6/16/22
to
Hi,
On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote:
> If you look at Debian 'testing' only, I think that the only remaining
> way to do that is 1.0 + quilt (packages that were using dpatch have all
> been converted or removed from testing).
That's good. I wasn't able to locate a counter example. Yet, the
situation is not quite what I'd like it to be.
Let me pull some example:
* Manually stacking patches on top of 3.0 (quilt):
https://sources.debian.org/src/libreoffice/1:7.3.4%7Erc2-1/debian/rules/?hl=2048#L2048
* dpatch in unstable, but not testing:
https://sources.debian.org/src/qmc/0.94-4/debian/rules/?hl=11#L3
* cdbs patchsys in unstable, but not testing:
https://sources.debian.org/src/sdic/2.1.3-22.1/debian/rules/?hl=5#L5
* cdbs patchsys in testing:
https://sources.debian.org/src/byacc-j/1.15-1.1/debian/rules/?hl=10#L10
https://sources.debian.org/src/phnxdeco/0.33-3.1/debian/rules/?hl=7#L7
https://sources.debian.org/src/aview/1.3.0rc1-9.1/debian/rules/?hl=20#L20
* 3.0 (quilt) with custom patch system:
https://sources.debian.org/src/golang-github-rogpeppe-go-internal/1.8.1-1/debian/rules/?hl=9#L9
Also the known ones: curl, gcc, glibc
Yet, it shows that quite some progress has been made on improving
consistency. Thank you for that work.
> According to https://udd.debian.org/~lucas/format10.cgi (which is based
> on what lintian knows about the archive), there are 114 packages using
> 1.0 with quilt. However, 67 of those are maintained by the Debian X
> team. If you plan to discontinue 1.0+patch-system in the context of
> this bug, it would probably be a good idea to have a discussion with
> them to better understand their use case.
Those Debian X packages at least provide internal (to the team)
consistency. Their workflow is a bit unique in that upstream commits may
be cherry picked directly and all other changes should use quilt
patches. I'm inclined to agree that telling X people they must switch
their workflow is not a useful outcome here. On the other hand, we're
giving non-binding advice here and that advice is a recommendation.
In any case, your argument makes 4c a more attractive option to me. Keep
in mind though that the rationale given in 4c, does not really cover the
Debian X workflow. So it may still be read as a recommendation for
Debian X to change (or not).
> I personally think that it would be enough for this bug to issue a clear
> statement that we want to move away from 1.0 unless there's a good
> reason, on a per-package basis, not to. That would create a mandate to
> work on surveying the remaining packages and identifying the remaining
> use cases. That would also allow motivated volunteers to work on
> migrating the remaining packages when there's no reason to stay with
> 1.0, using the NMU procedure if needed.
Indeed, and I do agree that 4c is such a clear statement. I would like
to see a stronger statement here, but Sam et al. tried to gain consensus
on that and there wasn't. So the CTTE advice probably shouldn't override
that non-consensus. That makes 4c a lot more of an attractive option to
me. Finally, the main conflicting parties in this issue (oversimplified)
were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as
well.
I hereby withdraw my intention to extend the ballot as sent by Sean on
June 7th.
Thanks for bearing with me and bringing those arguments forward.
Helmut
On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote:
> If you look at Debian 'testing' only, I think that the only remaining
> way to do that is 1.0 + quilt (packages that were using dpatch have all
> been converted or removed from testing).
situation is not quite what I'd like it to be.
Let me pull some example:
* Manually stacking patches on top of 3.0 (quilt):
https://sources.debian.org/src/libreoffice/1:7.3.4%7Erc2-1/debian/rules/?hl=2048#L2048
* dpatch in unstable, but not testing:
https://sources.debian.org/src/qmc/0.94-4/debian/rules/?hl=11#L3
* cdbs patchsys in unstable, but not testing:
https://sources.debian.org/src/sdic/2.1.3-22.1/debian/rules/?hl=5#L5
* cdbs patchsys in testing:
https://sources.debian.org/src/byacc-j/1.15-1.1/debian/rules/?hl=10#L10
https://sources.debian.org/src/phnxdeco/0.33-3.1/debian/rules/?hl=7#L7
https://sources.debian.org/src/aview/1.3.0rc1-9.1/debian/rules/?hl=20#L20
* 3.0 (quilt) with custom patch system:
https://sources.debian.org/src/golang-github-rogpeppe-go-internal/1.8.1-1/debian/rules/?hl=9#L9
Also the known ones: curl, gcc, glibc
Yet, it shows that quite some progress has been made on improving
consistency. Thank you for that work.
> According to https://udd.debian.org/~lucas/format10.cgi (which is based
> on what lintian knows about the archive), there are 114 packages using
> 1.0 with quilt. However, 67 of those are maintained by the Debian X
> team. If you plan to discontinue 1.0+patch-system in the context of
> this bug, it would probably be a good idea to have a discussion with
> them to better understand their use case.
consistency. Their workflow is a bit unique in that upstream commits may
be cherry picked directly and all other changes should use quilt
patches. I'm inclined to agree that telling X people they must switch
their workflow is not a useful outcome here. On the other hand, we're
giving non-binding advice here and that advice is a recommendation.
In any case, your argument makes 4c a more attractive option to me. Keep
in mind though that the rationale given in 4c, does not really cover the
Debian X workflow. So it may still be read as a recommendation for
Debian X to change (or not).
> I personally think that it would be enough for this bug to issue a clear
> statement that we want to move away from 1.0 unless there's a good
> reason, on a per-package basis, not to. That would create a mandate to
> work on surveying the remaining packages and identifying the remaining
> use cases. That would also allow motivated volunteers to work on
> migrating the remaining packages when there's no reason to stay with
> 1.0, using the NMU procedure if needed.
to see a stronger statement here, but Sam et al. tried to gain consensus
on that and there wasn't. So the CTTE advice probably shouldn't override
that non-consensus. That makes 4c a lot more of an attractive option to
me. Finally, the main conflicting parties in this issue (oversimplified)
were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as
well.
I hereby withdraw my intention to extend the ballot as sent by Sean on
June 7th.
Thanks for bearing with me and bringing those arguments forward.
Helmut
gregor herrmann
Jun 16, 2022, 7:10:04 PM6/16/22
to
On Wed, 15 Jun 2022 11:08:59 +0100, Ian Jackson wrote:
> Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
> > Simon looked at how other distributions approach patches and figured
> > that basically everyone else uses the patches-unapplied model.
> patches-unapplied is a good fit for distro experts in distros which
> are still using tarballs-and-patches.
And that's what we are talking about: Debian experts building
> Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
> > Simon looked at how other distributions approach patches and figured
> > that basically everyone else uses the patches-unapplied model.
> patches-unapplied is a good fit for distro experts in distros which
> are still using tarballs-and-patches.
packages for Debian. At least that's what my priorities are.
> (IME most Debian insiders severly underestimate the scale of the
> problems faced by a random user who is already a programmer and just
> wants to make some change to a package.)
"random users who know git but not Debian packaging".
Taking a step back: I think all those idiosyncrasies and the need to
learn weird things to build packages and the impossibility to Just
Use Git are a sad thing and bad for anyone involved. But we won't fix
these problems by adding yet another layer of workarounds and
indirection; unless we can address the problem at its root this will
all be futile.
> Happily, it is possible to reconcile the disagreement about applied vs
> unapplied by automatically converting. dgit, and Sean and my
> tag2upload system, do precisely this, in the "forward" direction,
> which is the most important one.
Just that it needs to be accepted at the archive level, i.e. by the
FTPmasters. Until then it's unfortunately "a nice idea". So more
technical work or more advice by the TC won't help in any way.
And dgit also is just a nice workaround for the problem that the
canonical source of Debian packages is not Git repo; it pretends that
there is, and it stumbles across all kinds of corner cases caused by
how source packages look like nowadays.
This is not a criticism of tag2upload or dgit; quite to the contrary
I think that they identify real problems. But they just create
additional layers and try to create workarounds. And that's all they
can do without further (political) changes.
Back to the topic of this bug report: The TC was asked for advice
about source formats (and patch systems), and as their resolution
can't change how the archive works, I very much agree with Helmut
that more uniformity and less pathogenic packages are indeed very
helpful.
And if we want to change the source package basics themselves: Yay,
but that's a different question at a different level.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
gregor herrmann
Jun 16, 2022, 8:50:03 PM6/16/22
to
On Thu, 16 Jun 2022 16:56:24 -0700, Sean Whitton wrote:
> On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote:
> > And that's what we are talking about: Debian experts building
> > packages for Debian. At least that's what my priorities are.
> I think Ian might really mean "Debian source package experts".
That was not my impression, as he wrote (not quoted in my reply):
| One of my friends - an expert programmer (and expert user of git) -
| did precisely that, prompting my post.
> It ought
> to be our goal to make it so that you can be a Debian expert without
> being a Debian source package expert. It also seems worth mentioning
> that users wanting to apply patches to packages installed on their
> systems are also one of priorities.
Well, yes, sure.
That would all be nice.
But issuing some advice about 1.0-with-or-without-dpatch or whatever
doesn't really change anything for them.
(Again: No criticism of the TC, as there is some question and as there
are some, hm, organizational boundaries.)
> > And dgit also is just a nice workaround for the problem that the
> > canonical source of Debian packages is not Git repo; it pretends that
> > there is, and it stumbles across all kinds of corner cases caused by
> > how source packages look like nowadays.
> I would challenge this idea: at this point, the canonical source of very
> many Debian packages is indeed their git repos on salsa. Not all of
> them, but very many.
Oh, right, I totally agree that for all practical reasons the
practical source of most of the packages I upload are in a salsa
git repo.
But that's completely irrelevant.
What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz
*.dsc an some web mirrors.
> On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote:
> > And that's what we are talking about: Debian experts building
> > packages for Debian. At least that's what my priorities are.
That was not my impression, as he wrote (not quoted in my reply):
| One of my friends - an expert programmer (and expert user of git) -
| did precisely that, prompting my post.
> to be our goal to make it so that you can be a Debian expert without
> being a Debian source package expert. It also seems worth mentioning
> that users wanting to apply patches to packages installed on their
> systems are also one of priorities.
Well, yes, sure.
That would all be nice.
But issuing some advice about 1.0-with-or-without-dpatch or whatever
doesn't really change anything for them.
(Again: No criticism of the TC, as there is some question and as there
are some, hm, organizational boundaries.)
> > And dgit also is just a nice workaround for the problem that the
> > canonical source of Debian packages is not Git repo; it pretends that
> > there is, and it stumbles across all kinds of corner cases caused by
> > how source packages look like nowadays.
> many Debian packages is indeed their git repos on salsa. Not all of
> them, but very many.
Oh, right, I totally agree that for all practical reasons the
practical source of most of the packages I upload are in a salsa
git repo.
But that's completely irrelevant.
What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz
*.dsc an some web mirrors.
Sam Hartman
Jun 17, 2022, 12:50:04 PM6/17/22
to
>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes:
Helmut> Indeed, and I do agree that 4c is such a clear statement. I
Helmut> would like to see a stronger statement here, but Sam et
Helmut> al. tried to gain consensus on that and there wasn't. So the
Helmut> CTTE advice probably shouldn't override that
Helmut> non-consensus. That makes 4c a lot more of an attractive
Helmut> option to me.
Actually, I think the TC making a decision when the project is unable to
come to consensus is often a great outcome.
The TC is one of our decision making options. During my DPL term, the
TC did not appear to have the credibility to be a popular option for me
to go to when my consensus-making attempts got part of the way.
However, if the project is functioning well, I think that the TC is a
great option short of a GR.
I think that has worked well with usrmerge recently.
I DO NOT think this bug is the place for the TC to recommend something
like the maintainer view of git source packages should be a
patches-unapplied format.
I think it would be great if the TC would take that on in a separate
bug.
If you would like me to pose such a question to the TC I'd be happy to
do so.
Driving a GR discussion on that issue is too much for me, but posing a
question to the TC is within the energy I have available.
--Sam
Helmut> Indeed, and I do agree that 4c is such a clear statement. I
Helmut> would like to see a stronger statement here, but Sam et
Helmut> al. tried to gain consensus on that and there wasn't. So the
Helmut> CTTE advice probably shouldn't override that
Helmut> non-consensus. That makes 4c a lot more of an attractive
Helmut> option to me.
Actually, I think the TC making a decision when the project is unable to
come to consensus is often a great outcome.
The TC is one of our decision making options. During my DPL term, the
TC did not appear to have the credibility to be a popular option for me
to go to when my consensus-making attempts got part of the way.
However, if the project is functioning well, I think that the TC is a
great option short of a GR.
I think that has worked well with usrmerge recently.
I DO NOT think this bug is the place for the TC to recommend something
like the maintainer view of git source packages should be a
patches-unapplied format.
I think it would be great if the TC would take that on in a separate
bug.
If you would like me to pose such a question to the TC I'd be happy to
do so.
Driving a GR discussion on that issue is too much for me, but posing a
question to the TC is within the energy I have available.
--Sam
Helmut Grohne
Jun 23, 2022, 11:10:04 AM6/23/22
to
Rationale
A key issue on this ballot to me is consistency of the archive. Given
that 1.0 source formats have mostly vanished, deprecating the remainder
is reasonable. While I would have liked a deprecation decision for all
1.0 formats in all cases, this is not project consensus yet and we're
taking a smaller step here. Meanwhile, this recommendation enables work
to continue getting rid of 1.0 formats. Since 4a can be read as an
endorsement, I prefer excluding it. The longer version is to be found in
the discussion mails.
Helmut
Niko Tyni
Jun 26, 2022, 5:30:03 PM6/26/22
to
On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
I vote: C > A > X > N
--
Niko Tyni nt...@debian.org
Sean Whitton
Jun 27, 2022, 12:30:03 PM6/27/22
to
With three first preference votes for A and five first preference votes
for C, the outcome is no longer in doubt. Therefore, using its powers
Sean Whitton
for C, the outcome is no longer in doubt. Therefore, using its powers
under constitution 6.1.5, the Technical Committee issues the following
advice:
1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.
2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).
3. We suggest that the wontfix tag on #737634 be reconsidered.
4. We believe that there are indeed circumstances in which
advice:
1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.
2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).
3. We suggest that the wontfix tag on #737634 be reconsidered.
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
circumstances, to simplify the contents of the archive.
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
circumstances, to simplify the contents of the archive.
This is because there is currently no other source format which is
such that avoid both (i) uploading the whole source, including
upstream, for every upload; and (ii) having to maintain
debian/patches/ inside the package tree.
such that avoid both (i) uploading the whole source, including
upstream, for every upload; and (ii) having to maintain
debian/patches/ inside the package tree.
5. We decline to comment on the recent source package format MBF.
--
Sean Whitton
Sean Whitton
Nov 14, 2023, 1:42:47 PM11/14/23
to
Hello dpkg maintainers,
On Fri 03 Nov 2023 at 12:20pm +01, Bastian Blank wrote:
>> 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>> complain, when a non-native version number is used w/ 3.0 (native).
>> 3. We suggest that the wontfix tag on #737634 be reconsidered.
>
> No reply by the dpkg maintainer showed up. Do we need to revisit that?
Quick ping on the TC decision in #1007717: do you have any response to
the TC's advice? Thanks.
--
Sean Whitton
On Fri 03 Nov 2023 at 12:20pm +01, Bastian Blank wrote:
>> 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>> complain, when a non-native version number is used w/ 3.0 (native).
>> 3. We suggest that the wontfix tag on #737634 be reconsidered.
>
Quick ping on the TC decision in #1007717: do you have any response to
the TC's advice? Thanks.
--
Sean Whitton
0 new messages