I think that we should reduce the number of packages using the 1.0 format, as (1) format 3.0 has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices, lowering the bar for contributors to contribute to those packages.inn is a bit peculiar. It uses a patch system, has no direct changes and
The breakdown in terms of packages count is:
patch_system | direct_changes | vcs | count --------------+----------------+-----+-------
dpatch | no | no | 3
quilt | no | no | 26
quilt | no | yes | 96
none | no | no | 185
none | no | yes | 78
none | yes | no | 166
none | yes | yes | 74
I propose to file bugs for packages in all categories above, except for packages in the last category that are maintained in an active VCS repository, because those are the most likely to be be using a git
workflow that makes it hard to use the 3.0 format (even if I don't fully understand the arguments against using single-debian-patch in that
case).
I propose to file bugs using the following template, and make them Severity: serious after a month (minimum).
------------------------------------------------------>8
Subject: upgrade to 3.0 source format
Severity: important
So I'd rather propose to file these bugs with severity 'normal' and then wait and then get policy updated, and then raise the severity further.
On Mar 06, Lucas Nussbaum <lucas@debian.org> wrote:
I think that we should reduce the number of packages using the 1.0 format, asinn is a bit peculiar. It uses a patch system, has no direct changes and
(1) format 3.0 has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices, lowering the bar for contributors to
contribute to those packages.
is maintained in a VCS. But the build process is from a different age
and quite arcane, and I remember that switching to 3.0 would have
required significant work, so I see no compelling reason to do it.
Wouter Verhelst <wouter@debian.org>
aspic
logtool
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
Wouter Verhelst <wouter@debian.org>
aspic
logtool
Yeah, no. These will be reduced to "wishlist" and probably tagged
"wontfix".
The packages work just fine, the source format is still supported, I
have better things to do with my time?
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
Wouter Verhelst <wouter@debian.org>
aspic
logtool
Yeah, no. These will be reduced to "wishlist" and probably tagged
"wontfix".
...
I think that we should reduce the number of packages using the 1.0 format, as (1) format 3.0 has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices, lowering the bar for contributors to contribute to those packages.
...
pngmeta
pngnq
libimage-metadata-jpeg-perl
pixelize
src2tex
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
I think that we should reduce the number of packages using the 1.0 format, as
(1) format 3.0 has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices, lowering the bar for contributors to
contribute to those packages.
...
You are not making a compelling case that these benefits clearly
outweight the substantial costs.
Such a MBF also:
(1) causes a lot of extra work, and
(2) causes a lot of breakage because such larger packaging changes
are rarely done as careful as would be necessary
When people are making invasive packaging changes like a dh compat bump
or change the packaging due to such a MBF we often end up with bug
reports like #1000229 where something broke due to that (empty binary packages are among the more typical breakages).
Unless a compelling case is made that the benefits of a MBF clearly
outweight these drawbacks, such MBFs usually have a negative benefit.
lintian already warns or has info tags that should be upgraded to warning,
and then there will be slow migrations usually happening when someone
anyway does (and tests!) larger packaging changes.
Ensuring that all relevant lintian tags are warnings would be the
appropriate action (which is not yet true[1]), but there is no urgency
on getting everything "fixed" immediately.
[1] https://lintian.debian.org/tags/older-source-format
Hi Adrian,
Am Mon, Mar 07, 2022 at 11:42:42PM +0200 schrieb Adrian Bunk:
...
lintian already warns or has info tags that should be upgraded to warning,
I absolutely agree here.
and then there will be slow migrations usually happening when someone anyway does (and tests!) larger packaging changes.
This "someone anyway does larger packaging changes" did not seem very probable for the packages I've touched (see my other mail in this
thread).
Ensuring that all relevant lintian tags are warnings would be the appropriate action (which is not yet true[1]), but there is no urgency
on getting everything "fixed" immediately.
I agree that there is no real urgency for immediate action - but this
seemed to be the case for other bugs on the packages I've touched the
case as well.
Kind regards
Andreas.
...
On Tue, Mar 08, 2022 at 11:39:04AM +0100, Andreas Tille wrote:
Hi Adrian,
Hi Andreas,
Am Mon, Mar 07, 2022 at 11:42:42PM +0200 schrieb Adrian Bunk:
...
lintian already warns or has info tags that should be upgraded to warning,
I absolutely agree here.
and then there will be slow migrations usually happening when someone anyway does (and tests!) larger packaging changes.
This "someone anyway does larger packaging changes" did not seem very probable for the packages I've touched (see my other mail in this
thread).
Ensuring that all relevant lintian tags are warnings would be the appropriate action (which is not yet true[1]), but there is no urgency
on getting everything "fixed" immediately.
I agree that there is no real urgency for immediate action - but this seemed to be the case for other bugs on the packages I've touched the
case as well.
what time frame do you have in mind when you write "no real urgency"
and "did not seem very probable"?
For me a reasonable time frame for changes that are neither urgent nor supposed to create user-visible changes in the binary packages would be
to ensure it is a lintian warning now, and then wait 10 years.
Many maintainers touch their packages at least once per release cycle
and also check lintian warnings, so many packages will get fixed within
the next 1-2 years.
Most packages will get a new maintainer or a new team member in an
existing maintainance team within the next 10 years, and with the
help of a lintian warning this is the natural time for doing such
changes.
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
...
I think that we should reduce the number of packages using the 1.0 format, as
(1) format 3.0 has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices, lowering the bar for contributors to
contribute to those packages.
...
You are not making a compelling case that these benefits clearly
outweight the substantial costs.
Such a MBF also:
(1) causes a lot of extra work, and
(2) causes a lot of breakage because such larger packaging changes
are rarely done as careful as would be necessary
When people are making invasive packaging changes like a dh compat bump
or change the packaging due to such a MBF we often end up with bug
reports like #1000229 where something broke due to that (empty binary packages are among the more typical breakages).
Unless a compelling case is made that the benefits of a MBF clearly outweight these drawbacks, such MBFs usually have a negative benefit.
I agree that there is no real urgency for immediate action - but this seemed to be the case for other bugs on the packages I've touched the
case as well.
what time frame do you have in mind when you write "no real urgency"
and "did not seem very probable"?
For me a reasonable time frame for changes that are neither urgent nor supposed to create user-visible changes in the binary packages would be
to ensure it is a lintian warning now, and then wait 10 years.
Many maintainers touch their packages at least once per release cycle
and also check lintian warnings, so many packages will get fixed within
the next 1-2 years.
Most packages will get a new maintainer or a new team member in an
existing maintainance team within the next 10 years, and with the
help of a lintian warning this is the natural time for doing such
changes.
...
So now we have 364 source packages for which we have a patch and for which we can show that this patch does not change the build output. Do you agree that with those two properties, the advantages of the 3.0 (quilt) format are sufficient such that the change shall be implemented at least for those 364?
Thanks!
cheers, josch
...
1/ the arguments about using patches to track changes to upstream code.
Among the ~600 packages in that potential MBF, there are still many that
make changes to upstream code, which are not properly documented. I
believe that it is widely accepted that seperate patches in
debian/patches/ are the recommended way to manage changes to upstream code (good way to help with those changes getting reviewed, getting merged upstream, etc.)
...
3/ the arguments about standardization/simplication of packaging
practices, that make it easier (1) for contributors to contribute to any package (think security support, NMUers, but also derivatives);
...
You argue that it's fine to wait 10 years for a transition such as the
switch to 3.0 (quilt). Actually, it has already been 11 years, since
3.0 (quilt) was introduced around 2011
...
What we are talking about here is the "end game": there are less than 2%
of packages in testing that are still using 1.0,
...
Lucas
If you're going to omit the ones in the last category, I think you should also omit the ones in the none/no/yes category, since they may be packages that intermittantly have changes and are similarly using a VCS-based
workflow that doesn't want to use the 3.0 format.
A mass bug filing for the first three categories seems like the change
with the biggest potential to benefit Debian, since it's a direct simplification of the number of ways packages are maintained in the
archive. The packages without any patch system feel a bit less
interesting.
1/ the arguments about using patches to track changes to upstream code.
Among the ~600 packages in that potential MBF, there are still many that
make changes to upstream code, which are not properly documented. I
believe that it is widely accepted that seperate patches in
debian/patches/ are the recommended way to manage changes to upstream code (good way to help with those changes getting reviewed, getting merged upstream, etc.)
I did exactly that and rebuilt all the packages found by Lucas with the following changes:
$ mkdir -p debian/source
$ echo '3.0 (quilt)' >debian/source/format
141 source packages produce bit-by-bit reproducible binary packages after applying this change:
[..]
An additional 223 source packages produce bit-by-bit reproducible binary packages after applying this change:
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.
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?
Also, how would that work with packages that combine direct changes to upstream, and quilt for Debian-created patches?
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?
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?
On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
Also, how would that work with packages that combine direct changes to upstream, and quilt for Debian-created patches?
Could you expand? I didn't think this category was one of the ones Russ
and I were talking about.
Could we only have "3.0 (quilt)" then, no "3.0 (native)"? Or, put differently, if you had a "native" package that is using a Debian
revision and we allow that, what difference is left between "3.0
(native)" and "3.0 (quilt)"?
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.
"Steve" == Steve McIntyre <steve@einval.com> writes:
https://udd.debian.org/cgi-bin/format10.cgi provides the list of
packages for each category. The packages count is currently:
(1.1): 53 packages
(1.2): 424 packages
(2): 149 packages
On Thu, Mar 10, 2022 at 09:49:50PM +0100, Lucas Nussbaum wrote:
...
For packages in (1.1) and (1.2), I propose to file Severity: wishlist
bugs using the following template:
------------------------------------------------------>8
Subject: please consider upgrading to 3.0 source format
Severity: wishlist
Usertags: format1.0
Dear maintainer,
This package is among the few (1.9%) that still use source format 1.0 in bookworm. Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.
Please note that this is also a sign that the packaging of this software could maybe benefit from a refresh. It might be a good opportunity to
look at other aspects as well.
This mass bug filing was discussed on debian-devel@: https://lists.debian.org/debian-devel/2022/03/msg00074.html
...
josch already has tested patches for more than half of the packages,
starting by submitting bugs for these packages with these patches will
avoid work for maintainers and result in faster fixing of the bugs.
...
For packages in (1.1) and (1.2), I propose to file Severity: wishlist
bugs using the following template:
------------------------------------------------------>8
Subject: please consider upgrading to 3.0 source format
Severity: wishlist
Usertags: format1.0
Dear maintainer,
This package is among the few (1.9%) that still use source format 1.0 in bookworm. Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Please note that this is also a sign that the packaging of this software could maybe benefit from a refresh. It might be a good opportunity to
look at other aspects as well.
This mass bug filing was discussed on debian-devel@: https://lists.debian.org/debian-devel/2022/03/msg00074.html
...
Lucas
Why on earth *would* you mess around using Debian revisions on a native-format package, though? IMHO it's pointless and is just going
to confuse people. Unless you can explain a good reason to need this,
I'd argue strongly that the 3.0 native support is DTRT for the
principle of least surprise if nothing else!
You're trying to produce packages from CI builds or other automation
where you sometimes have native Debian revisions.
* you are producing a package where you have distinct upstream and
debian branches, and you cannot control the upstream version number.
You want to do everything in git, and not have to deal with quilt
patches.
Say you don't even have any patches, but you sometimes do produce new
revisions simply for changes to debian control files and the like.
* You are trying to local (or downstream) builds of debian packages that
do have debian revision numbers.
You want to do everything in git because honestly dealing with dscs is
a PITA and if you can avoid it you want to.
You need to produce dscs to feed to sbuild, or mini-buildd or something.
But you just want to do that easily from your git CI pipelines.
My frustrations with the number of hours I've lost because of this
doctrinal issue has caused me to come close to giving up on Debian more
than once.
Part of that is frustration around how the change was handled and how concerns and use cases where not considered and dismissed without consideration.
But part of that is how I've had to hack around the isue in every
downstream CI environment where I took Debian packages and modified
them.
There are 629 packages in bookworm that use source format 1.0. That's 1.9% of bookworm packages.
On 09/03/22 at 08:52 -0700, Sean Whitton wrote:
On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
Also, how would that work with packages that combine direct changes to
upstream, and quilt for Debian-created patches?
Could you expand? I didn't think this category was one of the ones Russ
and I were talking about.
My limited understanding of the landscape of git workflows is that a
workflow that is quite popular among packages still using the 1.0 format
is the one used by the Debian X strike force. Julien Cristau described
it as follows when I asked about it on IRC:
< jcristau> [...] basically, for upstream patches we cherry-pick
commits directly, and we use quilt for changes that aren't upstream
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.
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.
"Guillem" == Guillem Jover <guillem@debian.org> writes:
You're trying to produce packages from CI builds or other automation
where you sometimes have native Debian revisions.
* you are producing a package where you have distinct upstream and
debian branches, and you cannot control the upstream version number.
Doesn't this make it 'not a native debian package'?
I thought the whole point of debian native packages was that there was
no 'upstream' and it was only for debian so you _are_ in control of
the source, the versioning and the releases?
As soon as that stops
being true then should one not shift to making it a standard
'upstream+debian revision' non-native package?
"Steve" == Steve McIntyre <steve@einval.com> writes:
Steve> Why on earth *would* you mess around using Debian revisions
Steve> on a native-format package, though?
You're trying to produce packages from CI builds or other automation
where you sometimes have native Debian revisions.
* you are producing a package where you have distinct upstream and
debian branches, and you cannot control the upstream version number.
I think we can all agree upon bumping the lintian severity to
warning.
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.
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.
yes, we should convert all native packages in our archive,
the idea of a native package has been obsoleted for long.
It's probably unfashionable, but I think debian/patches is not a greatThat's just a consequence of using two different storage formats for your packages: a Debian source package and a VCS. As long as both of them are widely used and incompatible, problems will exist in some form when using both.
way to manage changes, particularly if you're using a VCS for
maintaining your packages. As others have pointed out in this thread,
doing this means you end up essentially trying to version-control your patches twice - once in the source package, and once in the VCS.
1/ the arguments about using patches to track changes to upstream code.
Among the ~600 packages in that potential MBF, there are still many that
make changes to upstream code, which are not properly documented. I
believe that it is widely accepted that seperate patches in
debian/patches/ are the recommended way to manage changes to upstream code
Sean Whitton writes ("Re: proposed MBF: packages still using source format 1.0"):...
[questions]
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.
But I see now that the MBF has gone ahead anyway.
I spent some time trying to help by setting out the factual
background, but it seems that Debian is not interested in facts. I
don't know why I bother.
On Tue, Mar 15, 2022 at 08:54:50AM +0000, Matthew Vernon wrote:
It's probably unfashionable, but I think debian/patches is not a greatThat's just a consequence of using two different storage formats for your packages: a Debian source package and a VCS. As long as both of them are widely
way to manage changes, particularly if you're using a VCS for
maintaining your packages. As others have pointed out in this thread,
doing this means you end up essentially trying to version-control your
patches twice - once in the source package, and once in the VCS.
used and incompatible, problems will exist in some form when using both.
By e.g. merging all patches in the Debian source package into one big diff you are just breaking one of these two storage formats for that package, essentially mandating the usage of the other one (the VCS) for most of the developer operations with it.
Hello,
On Wed 09 Mar 2022 at 05:15PM +01, Lucas Nussbaum wrote:
On 09/03/22 at 08:52 -0700, Sean Whitton wrote:
On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
Also, how would that work with packages that combine direct changes to >> > upstream, and quilt for Debian-created patches?
Could you expand? I didn't think this category was one of the ones Russ >> and I were talking about.
My limited understanding of the landscape of git workflows is that a workflow that is quite popular among packages still using the 1.0 format
is the one used by the Debian X strike force. Julien Cristau described
it as follows when I asked about it on IRC:
< jcristau> [...] basically, for upstream patches we cherry-pick
commits directly, and we use quilt for changes that aren't upstream
Ah right, thank you. I wasn't really thinking of this case as being
about git workflows. Are the repos patches-applied or
patches-unapplied?
Which of my statements?It's probably unfashionable, but I think debian/patches is not a greatThat's just a consequence of using two different storage formats for your packages: a Debian source package and a VCS. As long as both of them are widely
way to manage changes, particularly if you're using a VCS for
maintaining your packages. As others have pointed out in this thread,
doing this means you end up essentially trying to version-control your
patches twice - once in the source package, and once in the VCS.
used and incompatible, problems will exist in some form when using both.
By e.g. merging all patches in the Debian source package into one big diff you are just breaking one of these two storage formats for that package, essentially mandating the usage of the other one (the VCS) for most of the developer operations with it.
I'm not sure that's entirely true;
but even if it were, is that an entirely unreasonable position for aProbably not? Just yet another case where you need to learn a specific
package maintainer (or team thereof) to take?
On Tue, Mar 15, 2022 at 10:49:17AM +0000, Matthew Vernon wrote:
but even if it were, is that an entirely unreasonable position for aProbably not? Just yet another case where you need to learn a specific workflow to modify or study a certain package, cannot use established documentation for that, and are required to use specific non-default tools for that.
package maintainer (or team thereof) to take?
Debian is not upstream, so it has a Debian revision. The package is maintained in git, and the source package is very small and it is not uploaded frequently. So we use a native source format. This means
that we must use format 1.0 because dpkg hates 3.0 native with debian revision.
Yes. People complain about the Debian packaging toolchain being too
complex or too confusing. This is one of such cases. As has been stated countless times, this subverts the semantics of both the source and
version formats. At least we only have one case remaining, the even
more senseless 1.0 non-native source with native version was turned
into an error with dpkg 1.20.1. Recall that dpkg-source currently needs
to use heuristics to decide whether to use an orig tarball + diff or not
for format 1.0. :(
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?
Ian Jackson writes ("Re: proposed MBF: packages still using source format 1.0"):
But I see now that the MBF has gone ahead anyway.
For example, consider a package maintained by a sponsee of mine:
Debian is not upstream, so it has a Debian revision. The package is maintained in git, and the source package is very small and it is not uploaded frequently. So we use a native source format. This means
that we must use format 1.0 because dpkg hates 3.0 native with debian revision.
As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html
I proceeded with the MBF for packages that match
not (debian_x or (vcs and vcs_status != 'ERROR' and direct_changes))
or, maybe easier to read:
(not debian_x) and ((not vcs) or vcs_status == 'ERROR' or (not direct_changes))
I did not file bugs for packages that are likely to use a VCS-based
workflow (category (2) in the mail pointed above, or in https://udd.debian.org/cgi-bin/format10.cgi)
Answers were given, including by a former DPL (whom you may observe
is not someone I am on speaking terms with).
But I see now that the MBF has gone ahead anyway.
I spent some time trying to help by setting out the factual
background, but it seems that Debian is not interested in facts. I
don't know why I bother.
At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:
its-playback-time
spigot
vm
vtwm
chroma
Clearly the it makes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.
However, given that I perceive that:
- there is a campaign to abolish 1.0
- there are important use cases where 1.0 is needed
- the campaign to abolish 1.0 is being prosecuted anyway
I have deliberately chosen to continue to upload even pure-native
packages as 1.0, to try to slow this process down in the hope that the situation improves and/or people stop trying to forbid useful things.
Something I might want to see though (although I hold not much hope
for) is a possible move away from the default behavior when no debian/source/format is present, as I think that gives bad defaults
for newcomers or inexperienced users, and even there just emitting
warnings tend to be ignored. Possible alternatives could be, either
erroring out, or changing the default format depending on say a
dpkg-compat level, or similar, I don't know, have not thought this
through though. But explicitly marking sources as 1.0 (as has been
warned for a long time now) would of course keep working as of right
now.
On Mon, Mar 14, 2022 at 01:10:19PM +0000, Wookey wrote:
You're trying to produce packages from CI builds or other automation where you sometimes have native Debian revisions.
* you are producing a package where you have distinct upstream and
debian branches, and you cannot control the upstream version number.
Doesn't this make it 'not a native debian package'?
yes, exactly, that's the problem.
I thought the whole point of debian native packages was that there was
no 'upstream' and it was only for debian so you _are_ in control of
the source, the versioning and the releases?
yes, that was the idea when native packages were introduced over
20 ago, when there were hardly any Debian forks, and certainly no
CI systems and other automated systems which 'constantly fork'.
As soon as that stops
being true then should one not shift to making it a standard 'upstream+debian revision' non-native package?
yes, we should convert all native packages in our archive,
the idea of a native package has been obsoleted for long.
column on https://udd.debian.org/cgi-bin/format10.cgi )
Andrey Rahmatullin <wrar@debian.org> writes:
On Tue, Mar 15, 2022 at 08:54:50AM +0000, Matthew Vernon wrote:
It's probably unfashionable, but I think debian/patches is not a greatThat's just a consequence of using two different storage formats for your packages: a Debian source package and a VCS. As long as both of them are widely
way to manage changes, particularly if you're using a VCS for
maintaining your packages. As others have pointed out in this thread,
doing this means you end up essentially trying to version-control your
patches twice - once in the source package, and once in the VCS.
used and incompatible, problems will exist in some form when using both.
By e.g. merging all patches in the Debian source package into one big diff you are just breaking one of these two storage formats for that package, essentially mandating the usage of the other one (the VCS) for most of the developer operations with it.
I'm not sure that's entirely true; but even if it were, is that an
entirely unreasonable position for a package maintainer (or team
thereof) to take?
On Wed, Mar 09, 2022 at 01:08:59PM +0100, Lucas Nussbaum wrote:
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?
Well. There is a specific source format now for full git workflows:
3.0 (gitarchive).
It is implemented outside of dpkg in it's own package
dpkg-source-gitarchive.
On Sun, Mar 13, 2022 at 02:58:31PM -0700, Sean Whitton wrote:
Hello,The patches that we keep in quilt are not applied in the repo.
On Wed 09 Mar 2022 at 05:15PM +01, Lucas Nussbaum wrote:
On 09/03/22 at 08:52 -0700, Sean Whitton wrote:
On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
Also, how would that work with packages that combine direct changes to >> >> > upstream, and quilt for Debian-created patches?
Could you expand? I didn't think this category was one of the ones Russ >> >> and I were talking about.
My limited understanding of the landscape of git workflows is that a
workflow that is quite popular among packages still using the 1.0 format >> > is the one used by the Debian X strike force. Julien Cristau described
it as follows when I asked about it on IRC:
< jcristau> [...] basically, for upstream patches we cherry-pick
commits directly, and we use quilt for changes that aren't upstream
Ah right, thank you. I wasn't really thinking of this case as being
about git workflows. Are the repos patches-applied or
patches-unapplied?
(Obviously the cherry-picked patches are.)
On 15/03/22 at 15:36 +0000, Ian Jackson wrote:
At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:
its-playback-time
spigot
vm
vtwm
chroma
Clearly the it makes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.
Those five packages:
- are indeed native packages with Debian revisions
- are not maintained in a VCS (or the VCS is not advertized using
Vcs-*).
So there's no easy way to understand how the package differs from
upstream (no patch serie, no VCS history). I don't think that it's
something desirable.
(if the packages had declared a VCS, they would have joined cachefilesd, userv-utils, and vde2 in the "native package with a Debian revision maintained in a VCS" category.)
Hello,
On Tue 15 Mar 2022 at 06:26PM +01, Lucas Nussbaum wrote:
On 15/03/22 at 15:36 +0000, Ian Jackson wrote:
At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:
its-playback-time
spigot
vm
vtwm
chroma
Clearly the it makes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.
Those five packages:
- are indeed native packages with Debian revisions
- are not maintained in a VCS (or the VCS is not advertized using
Vcs-*).
So there's no easy way to understand how the package differs from
upstream (no patch serie, no VCS history). I don't think that it's something desirable.
(if the packages had declared a VCS, they would have joined cachefilesd, userv-utils, and vde2 in the "native package with a Debian revision maintained in a VCS" category.)
They have detailed history on dgit-repos.
E.g. <https://browse.dgit.debian.org/its-playback-time.git/>.
On 28/03/22 at 16:03 -0700, Sean Whitton wrote:
Hello,
On Tue 15 Mar 2022 at 06:26PM +01, Lucas Nussbaum wrote:
On 15/03/22 at 15:36 +0000, Ian Jackson wrote:
At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:
its-playback-time
spigot
vm
vtwm
chroma
Clearly the it makes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.
Those five packages:
- are indeed native packages with Debian revisions
- are not maintained in a VCS (or the VCS is not advertized using
Vcs-*).
So there's no easy way to understand how the package differs from
upstream (no patch serie, no VCS history). I don't think that it's
something desirable.
(if the packages had declared a VCS, they would have joined cachefilesd, >> > userv-utils, and vde2 in the "native package with a Debian revision
maintained in a VCS" category.)
They have detailed history on dgit-repos.
E.g. <https://browse.dgit.debian.org/its-playback-time.git/>.
Yes, my point is that those packages don't have Vcs-* headers, so it's impossible to discover the above URL.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 32:42:06 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,199 |