On Tue, 2019-11-05 at 02:34:13 +0100, Guillem Jover wrote:
> I'm planning to add warnings for 1.0 formats when using a version that
> does not match the type of tarball found. Ideally 1.0 formats would
> error out in the same way 3.0 do, but this is impractical, and I guess
> we'll just have to
(Even though it was not clear in the initial mail, I'm assuming
this is about using native format 1.0 with non-native versions.)
On Fri, 2019-08-30 at 12:57:56 -0400, Sam Hartman wrote:
> My take away from this discussion though is that using a native package
> format even when there are
Sam Hartman writes:
> * One is that you're not using upstream tarballs. If upstream has
> tarballs they produce, we're not using them. I guess we may end up
> having that part of the conversation now rather than later.
>
> It's clear that we value integrity of upstream source. That is we
On Aug 30, Scott Kitterman wrote:
> It's not particularly rare for me to poke through other distros package
> patches when I'm trying to figure out how to solve a problem. I suspect I'm
I would even say that maintainers who do not periodically review what
other distributions do with their
Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> [context: git-debrebase, git-dpm]
>
> However, while analyzing a rebased branch isn't as hard for other
> people as a branch with a complex merge history, it does mean that
> upstream has to find
gregor herrmann writes ("Re: Git Packaging: Native source formats"):
> On Thu, 29 Aug 2019 22:03:18 -0400, Theodore Y. Ts'o wrote:
> > The problem I have is that "dgit gbp" doesn't extract the upstream
> > .asc.
>
> This sounds like #872864 in git-buil
On Fri, Aug 30, 2019 at 09:05:45AM -0700, Russ Allbery wrote:
> Ian Jackson writes:
> > This is also not that hard, in simple cases. There is a tool
> > git-debcherry which can do it automatically. I haven't used it but AIUI
> > if your Debian delta queue has few commits, and doesn't have
On Thu, 29 Aug 2019 22:03:18 -0400, Theodore Y. Ts'o wrote:
> The problem I have is that "dgit gbp" doesn't extract the upstream
> .asc.
This sounds like #872864 in git-buildpackage.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' :
On Fri, 2019-08-30 at 12:20 -0400, Scott Kitterman wrote:
> On Friday, August 30, 2019 12:05:45 PM EDT Russ Allbery wrote:
> > This lets you generate the patches for people on demand, but they aren't
> > just sitting out there for anyone to look at whenever they want.
> >
> > I suppose it could
> "Ian" == Ian Jackson writes:
Ian> I certainly agree with this. I don't think anyone is saying
Ian> that using (say) a merging git workflow with a native source
Ian> package format should be universal, or even the default.
Correct.
My take away from this discussion though is
On Fri, 30 Aug 2019 at 09:05:45 -0700, Russ Allbery wrote:
> [git-debcherry] lets you generate the patches for people on demand, but
> they aren't just sitting out there for anyone to look at whenever they want.
I think that's really important from the transparency point of view that
you touched
On Friday, August 30, 2019 12:05:45 PM EDT Russ Allbery wrote:
> Ian Jackson writes:
> > Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> >> [ discussion of benefits of maintaining the Debian delta as
> >>
> >
Ian Jackson writes:
> Russ Allbery writes ("Re: Git Packaging: Native source formats"):
>> [ discussion of benefits of maintaining the Debian delta as
>> a linear series of broken-down changes ]
>>
>> There are obviously ways to represent this with a p
Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> [ discussion of benefits of maintaining the Debian delta as
> a linear series of broken-down changes ]
>
> There are obviously ways to represent this with a pure Git repository, but
> apart from us
Philipp Kern writes ("Re: Git Packaging: Native source formats"):
> While this may be true on some level, it is also important to be able to
> build packages from checked-out source trees (say, git repositories)
> without an original source present.
Quite.
For example, if
Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote:
> > I think dgit ought to be compatible with the idea of shipping
> > upstream's .asc's about, but maybe there are bugs. I don't ever do
On Fri, Aug 30, 2019 at 12:29:45AM +0200, Thomas Goirand wrote:
> Now, you're talking about upstream using bzr or hg. These are the very
> few minority (and counting...). We may as well get rid of hg and bzr in
> Debian if it doesn't get fixed so it uses Python 3 only... (well, I
> guess someone
On Thu, Aug 29, 2019 at 01:26:08PM -0700, Russ Allbery wrote:
> While this is not an argument against *ever* using 3.0 (native) or some
> equivalent when packaging upstream software, I have found it to help
> relationships with upstream considerably in the past to represent the
> package as their
Hi,
On Thu, Aug 29, 2019 at 09:42:50PM +0200, Philipp Kern wrote:
> Obviously I'm not bound to that format being "3.0 (native)" but some
> "3.0 (dumb)" that just tars up the whole tree without caring about the
> version scheme would then be nice to have as a replacement. ;-)
Are you planning to
On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote:
> Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> > Or if we end up moving to dgit for everything, and we don't want to
> > use pristine-tar (which I like, but I realize that's
On Fri, Aug 30, 2019 at 12:29:45AM +0200, Thomas Goirand wrote:
>
> Pristine-tar forces you to have multiple branches when you may only need
> a single one. It's also not reliable and may easily generate different
> tarballs for the same tag, which defeats its purpose (and no, the
> workaround to
On 8/29/19 1:49 AM, Theodore Y. Ts'o wrote:
> Or if we end up moving to dgit for everything, and we don't want to
> use pristine-tar (which I like, but I realize that's not an opinion
> shared by everyone; some people seem to hate it
/me raises hand. I hate it.
Pristine-tar forces you to have
Sam Hartman writes:
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the same. You don't need to
On 2019-08-28, Sam Hartman wrote:
> * I've heard at least one person claim that native format packages are
> problematic for downstreams.
> I'd like to better understand both the theoretical argument here and
> to understand from downstreams whether it is an issue in practice.
>
> For
On 8/29/2019 8:32 PM, Andrej Shadura wrote:
>> So `3.0 (native)' is not strictly better than 1.0. dpkg-source
>> refuses to work in the situation where I am saying (and you seem to be
>> agreeing) that it shouldn't even print a warning ...
>
> I have to disagree with you but I consider this
On Thu, 29 Aug 2019 at 16:25:35 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > for
> > version 1.0 source packages, detecting a non-native version with a native
> > source format is the only way to gen
Ian Jackson writes ("Re: Git Packaging: Native source formats"):
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > Unlike 1.0 (non-native) vs. 3.0 (quilt), where some people prefer one and
> > some people prefer the other, I am not aware o
Milan Kupcevic writes ("Re: Git Packaging: Native source formats"):
> I've also seen developers deleting a git tag and then creating a new
> git tag using exactly the same name/release number pointing to
> different commit.
It is possible to avoid some of these problems by
Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> > If you already don't care about bit-identical upstream tarballs, then
> > dealing with these tarballs is a reasonably well-solved problem.
On 8/28/19 4:00 PM, Sam Hartman wrote:
>
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
> upstream, as well as to
On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> If you already don't care about bit-identical upstream tarballs, then
> dealing with these tarballs is a reasonably well-solved problem.
> git-deborig etc. FTW.
I think it's important to distinguish between the two things that you
might
Hi,
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote:
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
>
Sam Hartman writes ("Git Packaging: Native source formats"):
> Internet is faster and disks are cheaper.
> I assert this is much less of a concern than it used to be.
We have some extremely large packages. Also we have users in places
where internet is slow and/or expensive.
Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> Or if we end up moving to dgit for everything, and we don't want to
> use pristine-tar (which I like, but I realize that's not an opinion
> shared by everyone; some people seem to hate it), and upstream us
Hi,
On Wed, 28 Aug 2019, Sam Hartman wrote:
> Internet is faster and disks are cheaper.
I'm not sure that DSA (which is maintaining snapshot.debian.org) will
be happy with this assertion.
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you
> "Paul" == Paul Wise writes:
Paul> On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote:
>> Using native source formats (1.0 and 3.0 (native)) is attractive
>> for some git workflows. It means you can just export the git
>> repository and don't need to make sure that you use
On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote:
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote:
>
> But if we're thinking that people will be working in Git, another way
> to do this is to merge in a signed upstream git tag. Then you can
> perform a diff against that git tag.
One of the things to consider is how we should
On 2019-08-28 16:00:10 -0400 (-0400), Sam Hartman wrote:
[...]
> It seems particularly attractive when upstream doesn't produce
> tarballs and instead does their development in git.
[...]
Not to be a pedant, and it probably wasn't what you meant to imply
either, but I want to be clear that
Hi.
Back in the day, one of the big reasons for separating .orig.tar.gz from
.diff.gz was to reuse upstream tarballs for space reasons, both in terms
of space on mirrors when the pool had two Debian revisions with the same
upstream, as well as to reduce upload time.
Internet is faster and
40 matches
Mail list logo
