On Tue, May 10, 2022 at 08:32:32AM -0600, Sam Hartman wrote:
> > "Holger" == Holger Levsen writes:
> I'd much rather upload a 50M package regularly than deal with the vcs
> complexity of separate maintainer and upstream releases in a lot of
> cases.
> 10 years ago sure, that would have been
> "Holger" == Holger Levsen writes:
Holger> On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote:
>> > Even if that consensus does not exist, there is probably
>> consensus > that native packages are a poor match for large
>> packages (because of > the inefficiency
On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote:
> > Even if that consensus does not exist, there is probably consensus
> > that native packages are a poor match for large packages (because of
> > the inefficiency of making small updates to the packaging of native
> > packages),
>
Hi,
Russ Allbery wrote:
> Currently, Debian Policy is silent on when it's appropriate to use a
> native package, but there may be a project consensus aganist using
> native packages when the software has an existence outside of Debian.
I agree about this (modulo the bits discussed elsewhere in
> "Sean" == Sean Whitton writes:
Sean> Hello,
Sean> On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote:
>> To be clear, my understanding of the advocacy of using non-native
>> packages is primarily about their impact on *Debian* workflows
>> (being able to base
Hello,
On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote:
> To be clear, my understanding of the advocacy of using non-native packages
> is primarily about their impact on *Debian* workflows (being able to base
> multiple packages on the same tarball, not introducing confusion between
>
Sam Hartman writes:
> I'd propose the following way forward:
> 1) Capture the discussion thread we had during my DPL term and the
> things to think about that were brought up in the native packages part
> of that discussion.
> I'm not sure policy is the right place for those; I think some of
I do not support advising against using native packages with our current
tooling.
My issue is that for some work flows generating and keeping up with the
upstream tarballs significantly increases the frustration of packaging
and and brings doing a package update across a pain threshhold that
David Bremner writes:
> Russ Allbery writes:
>> Currently, Debian Policy is silent on when it's appropriate to use a
>> native package, but there may be a project consensus aganist using
>> native packages when the software has an existence outside of Debian.
> Personally I don't think Debian
Russ Allbery writes:
> Currently, Debian Policy is silent on when it's appropriate to use a
> native package, but there may be a project consensus aganist using
> native packages when the software has an existence outside of Debian.
Personally I don't think Debian policy should be concerned
Package: debian-policy
Version: 4.5.1.0
Severity: wishlist
Currently, Debian Policy is silent on when it's appropriate to use a
native package, but there may be a project consensus aganist using
native packages when the software has an existence outside of Debian.
Even if that consensus does not
11 matches
Mail list logo
