On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote:
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides. And working around quilt is simple:
>
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

Thanks for the recipes for avoiding the quilt stuff; whilst still more work
than "just use 1.0", but perhaps the advantages are indeed worth it. (Esp.
in light of the talk re: xz compression.)

> Except for nuking upstream debian/ dir which can mean a bit of lost work if
> the upstream is sane (and can save some if they're not), the 3.0 format is
> strictly better than 1.0.

I had to go away and read up on the other things 3.0 brings to the table.
Indeed they are nice-to-haves, which I am not benefiting from precisely because
they are presently only available in Debian via 3.0 (quilt). This is a bit of
a marketing fail for 3.0., in hindsight.



--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120516123707.GA6784@debian">http://lists.debian.org/20120516123707.GA6784@debian

Adam Borowski <kilobyte@angband.pl> writes:

> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides. And working around quilt is simple:

> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

I recommend using local-options instead of options. That way all of your
changes go into a single patch, but any NMUs automatically are put into
separate patches by version number. It makes analyzing packages that have
been NMU'd much nicer.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wr4cvy2a.fsf@windlord.stanford.edu">http://lists.debian.org/87wr4cvy2a.fsf@windlord.stanford.edu

Le Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski a écrit :
> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > > No, I hereby start saying good by to 3.0
> >
> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
> > few packages.
>
> I can't see any reason to use 1.0 anymore, ever.
>
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides. And working around quilt is simple:
>
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

It strikes me that while we have more than 6,500 source packages managed with
Git, we are pushing for a source package format that does not work
transparently with them.

Also, it is very sad that, as a project, we can not decide whether we go for
3.0 (git) or not, or have a concrete list of resolvable objections from the
people whose work is direclty impacted by the use of this format.

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120516230943.GD17262@falafel.plessy.net">http://lists.debian.org/20120516230943.GD17262@falafel.plessy.net

On Thu, 17 May 2012, Charles Plessy wrote:
> It strikes me that while we have more than 6,500 source packages
> managed with Git, we are pushing for a source package format that does
> not work transparently with them.

It does, but not on all workflows. A very large number of DDs are using
3.0 (quilt) with git just fine.

I don't exactly like quilt, in fact all my patch-based work is done
using stgit, but:

1) it is much better than dpatch and other homebrew stuff. At least you
know exactly what to expect, and it is the same in the entire distro.

2) properly used, it enforces neatness and lowers a damn great deal the
barrier of entry (*and* reduces the risk of mistakes) for someone who
needs to do quick maintenance, security updates, NMUs, when taking over
the package, and even for automated extraction of changes to upstream
code.

> Also, it is very sad that, as a project, we can not decide whether we
> go for 3.0 (git) or not, or have a concrete list of resolvable
> objections from the people whose work is direclty impacted by the use
> of this format.

This is a _very_ dead horse. I'd appreciate if you'd kindly refrain
from any further attempts at necromancy on this thread.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120517003922.GB8609@khazad-dum.debian.net">http://lists.debian.org/20120517003922.GB8609@khazad-dum.debian.net

Charles Plessy <plessy@debian.org> writes:

> Also, it is very sad that, as a project, we can not decide whether we go
> for 3.0 (git) or not, or have a concrete list of resolvable objections
> from the people whose work is direclty impacted by the use of this
> format.

We know what a primary concrete objection is. We discussed it at length
at DebConf two years ago, and then on debian-devel afterwards. Uploading
a Git archive requires reviewing the entire contents of the archive, not
just the current code, for licensing issues, which is pretty painful from
the ftp-master perspective.

There was never really a satisfactory resolution to that discussion. We
can upload very shallow clones, but they end up looking a lot like the
existing quilt format with single-debian-patch, and it's not horribly
clear what the advantages of 3.0 (git) are at that point. Many of the
really compelling use cases for 3.0 (git), neat stuff like possibly being
able to just push a signed tag instead of uploading or having the package
history when you get the source package, aren't very interesting with
shallow clones.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqa3seyj.fsf@windlord.stanford.edu">http://lists.debian.org/87pqa3seyj.fsf@windlord.stanford.edu

]] Russ Allbery

> There was never really a satisfactory resolution to that discussion. We
> can upload very shallow clones, but they end up looking a lot like the
> existing quilt format with single-debian-patch, and it's not horribly
> clear what the advantages of 3.0 (git) are at that point. Many of the
> really compelling use cases for 3.0 (git), neat stuff like possibly being
> able to just push a signed tag instead of uploading or having the package
> history when you get the source package, aren't very interesting with
> shallow clones.

Pushing a signed tag and having source packages and binaries built from
that doesn't rely on 3.0 (git), though. «Just» a repository somewhere
with hooks that go «oh, a signed tag, let me build a source package and
upload that». Might fire it off as a job to a separate process so
pushing to big repos doesn't take a winter and a day, but that's really
an implementation detail.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87likricaf.fsf@xoog.err.no">http://lists.debian.org/87likricaf.fsf@xoog.err.no

On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > > No, I hereby start saying good by to 3.0
> >
> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
> > few packages.
>
> I can't see any reason to use 1.0 anymore, ever.
>
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides. And working around quilt is simple:
>
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore

I'm confused concerning the above; the point of a VCS in this context is to
track changes to the source package, and the patches are themselves important
changes to the source package. If you have Git ignore the patches then Git
doesn't have a complete view of the source package anymore. Why would you
want to do that?

> and perhaps "rm -rf .pc debian/patches" in the clean target if those bother
> you -- and you have all the goodies that come with the 3.0 format, with
> getting none of quilt brain damage onto you. Suddenly, nothing conflicts
> with the VCS you're using, nothing breaks bisects, nothing causes spurious
> recompiles, etc.
>
> Except for nuking upstream debian/ dir which can mean a bit of lost work if
> the upstream is sane (and can save some if they're not), the 3.0 format is
> strictly better than 1.0.

If debian/ is nuked then so is debian/patches, and if Git has been told to
ignore debian/patches then it cannot bring those files back. Patching the
source can be an effort especially concerning documenting why the patches were
done and the source of the patches, so these seem like they'd be important to
track rather than something to ignore.

-- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

Chris Knadle <Chris.Knadle@coredump.us> writes:

> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> >
>> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
>> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
>> > few packages.
>>
>> I can't see any reason to use 1.0 anymore, ever.
>>
>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>> has a number of upsides. And working around quilt is simple:
>>
>> echo "single-debian-patch" >debian/source/options
>> echo "/.pc" >>.gitignore
>> echo "/debian/patches" >>.gitignore
>
> I'm confused concerning the above; the point of a VCS in this context is to
> track changes to the source package, and the patches are themselves important
> changes to the source package. If you have Git ignore the patches then Git
> doesn't have a complete view of the source package anymore. Why would you
> want to do that?

Git does have a complete view. What the above does, is tell dpkg-source
to fold any changes made to the upstream sources into a single
patch. Since the git tree already has the patches applied (with upstream
sources on a different branch, most probably), it has a full view.

This basically folds whatever patches the git tree has over upstream,
outside of debian/ into a single file. That's about it. Since that file
is generated, it has no business staying in git.

>> Except for nuking upstream debian/ dir which can mean a bit of lost work if
>> the upstream is sane (and can save some if they're not), the 3.0 format is
>> strictly better than 1.0.
>
> If debian/ is nuked then so is debian/patches, and if Git has been told to
> ignore debian/patches then it cannot bring those files back.

You're misreading this. "Nuking upstream debian/" means ignoring any
debian/ directory upstream may have had. That is generally a Good
Thing(tm), as we want to have our own packaging.

The original is still available in both the upstream tarball, and the
upstream branch. debian/patches in this case is irrelevant, as that is
automatically generated by diffing the upstream tree against the current
(git) tree and folding it into a single patch file.

> Patching the source can be an effort especially concerning documenting
> why the patches were done and the source of the patches, so these seem
> like they'd be important to track rather than something to ignore.

The reasons can - and should be - documented in git. Granted, that does
not transfer to the debianized source package, which is unfortunate, but
it's still better than fighting with integrating quilt with a VCS (in
which case, everyone with a higher number of patches would go back to
1.0 and custom patching systems and ignore every other benefit of 3.0,
because quilt and VCS generally don't play nice together).

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871umioo6l.fsf@algernon.balabit">http://lists.debian.org/871umioo6l.fsf@algernon.balabit

On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle wrote:
> I'm confused concerning the above; the point of a VCS in this context is to
> track changes to the source package, and the patches are themselves important
> changes to the source package. If you have Git ignore the patches then Git
> doesn't have a complete view of the source package anymore. Why would you
> want to do that?

It's the other way around. You manage changes to the source package as commits
in the VCS; perhaps tracked on separate branches, perhaps not. The source
package ends up being a flattened version of all of these commits. So the
'preferred form for modification' is the VCS archive; the source package is a
second class citizen.

So to follow Adam's instructions you would first apply each of the patches as a
commit in your VCS, then delete them, then ignore debian/patches going forward
(treating it as an implementation detail of a legacy source archive format)

Yes, I think it's a shame if the preferred form for modification wasn't the
source package. I also think it's turning a blind eye to say putting git
repos in as source packages would be not worth the work to audit them; but we
can keep hosting them at git.debian.org just fine.


--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120517145410.GB7703@debian">http://lists.debian.org/20120517145410.GB7703@debian

Tollef Fog Heen <tfheen@err.no> writes:

> Pushing a signed tag and having source packages and binaries built from
> that doesn't rely on 3.0 (git), though. «Just» a repository somewhere
> with hooks that go «oh, a signed tag, let me build a source package and
> upload that». Might fire it off as a job to a separate process so
> pushing to big repos doesn't take a winter and a day, but that's really
> an implementation detail.

Good point.

If I were to pick between the enhancements to Debian in this area, none of
which I have time to work on and therefore can't vote on via
implementation, I'd be way more interested in avoiding the entire source
package upload process entirely and be able to just push signed Git tags
to a trusted host that stores Git repositories for our packages. Even if
those repositories were only accessible to Debian maintainers because
they're not license-reviewed.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871umiy9r8.fsf@windlord.stanford.edu">http://lists.debian.org/871umiy9r8.fsf@windlord.stanford.edu