Hello,
On Tue 29 Mar 2022 at 09:06PM +02, Lucas Nussbaum wrote:
> On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
>>
>> I don't think it's the preferred method. I believe most of the project
>> sees git histories are the preferred tool for achieving the goal you
>> state.
>>
>> If we had only
On Tue, Mar 15, 2022 at 04:29:17PM +, 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
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:
>
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
>
> > A point that I find important is the following:
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
On 17/03/2022 17:52, Russ Allbery wrote:
Helmut Grohne 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
Hi Ian,
On 15/03/22 at 16:29 +, 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
Hi,
On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery 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
Sam Hartman writes:
>> "Russ" == Russ Allbery 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
> "Russ" == Russ Allbery 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
Helmut Grohne 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.
> Yes, please. Though as is evidenced in the replies to your mail,
> "Helmut" == Helmut Grohne writes:
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.
>>
On 16/03/22 at 23:54 +, Wookey wrote:
> On 2022-03-16 15:29 +, 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.
>
> > but almost everyone is already treating git as primary.
>
>
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.
On 2022-03-16 15:29 +, 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.
> but almost everyone is already treating git as primary.
Is this definitely true? For example: I know I'm not
Felix Lechner writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery 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
Helmut Grohne writes ("Re: Bug#1007717: Native source package format with
non-native version"):
> Beyond the content of your request, I have a meta-question. Do you see a
> particular urgency with the processing of your request? What is - in
> your opinion - a reasonable
Hi,
On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery 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
Sam Hartman 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.
I've been involved in a lot of these discussions over the years, and the
tentative conclusion
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
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)
Hi Ian,
On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson
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
Hi Ian,
On Tue, Mar 15, 2022 at 04:29:17PM +, 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.
ith 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 askin
> "Ian" == Ian Jackson 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
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
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,
26 matches
Mail list logo
