FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-03-2010, 09:25 PM
Matt Zagrabelny
 
Default git and quilt

Greetings,

I read through the git-buildpackage docs and also a HOWTO by Russ
Allbery [1] regarding git and Debian packaging. I am wondering if those
who use git to manage their source package development are also using
the debian/patches mechanism for modifying the upstream tarball.

I receive the following error from lintian and am looking for some
guidance/best practices.

% lintian --pedantic cdpr_2.3-3.dsc
P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
1 more

I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
package.

Thanks for the tips,

[1] http://www.eyrie.org/~eagle/notes/debian/git.html

--
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF C899 07E2 BFA8 42A0 0942

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot
 
Old 02-03-2010, 09:44 PM
Josselin Mouette
 
Default git and quilt

Le mercredi 03 février 2010 * 16:25 -0600, Matt Zagrabelny a écrit :
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

http://packages.debian.org/sid/topgit

--
.'`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
 
Old 02-03-2010, 10:08 PM
Russ Allbery
 
Default git and quilt

Matt Zagrabelny <mzagrabe@d.umn.edu> writes:

> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I generally do not. Doing so with a tool like TopGit is a little awkward
and requires more steps, and I don't see much utility in doing so. I
think it's easier to just manage Git branches.

--
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
 
Old 02-03-2010, 10:15 PM
James Vega
 
Default git and quilt

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I receive the following error from lintian and am looking for some
> guidance/best practices.
>
> % lintian --pedantic cdpr_2.3-3.dsc
> P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
> 1 more

This isn't an error. It's an informational message only shown in
pedantic mode. From lintian(1):

“Pedantic tags are Lintian at its most pickiest and include checks for
particular Debian packaging styles and checks that many people disagree
with. Expect false positives and Lintian tags that you don't consider
useful if you use this option.”

In other words, if you think the tag is useful then fix it, otherwise
ignore it.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 02-03-2010, 10:20 PM
martin f krafft
 
Default git and quilt

also sprach Russ Allbery <rra@debian.org> [2010.02.04.1208 +1300]:
> I generally do not. Doing so with a tool like TopGit is a little awkward
> and requires more steps, and I don't see much utility in doing so. I
> think it's easier to just manage Git branches.

All that TopGit really does is help you in merging depending
branches into dependent ones if the former have updated. You also
don't have to always update them, as TopGit works quite well even if
branches are out-of-date. tg-summary is still useful to keep an
overview.

But yes, there are still some open issues with TopGit that prevent
me from unconditionally adovating it.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=topgit;exclude=tags:fixed;exclud e=tags:fixed-upstream;exclude=tagsending;exclude=tags:wontfix ;exclude=pending:done;dist=unstable

--
.'`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems

"sometimes the urge to do bad is nearly overpowering"
-- ben horne
 
Old 02-04-2010, 07:21 AM
Stefano Zacchiroli
 
Default git and quilt

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I personally do (and we do the same thoroughly in a couple of teams I'm
involved with).

The idea is to keep the status stored in debian/patches/, fully
compatible with quilt and v3 source formats. Then, to manipulate patches
you create on the fly a "patch-queue" branch, where you have one commit
per patch. On that branch you do the changes you want (possibly
including rebases) and when you're done you "save" the branch in a new
series of patches to be stored in debian/patches/, throwing away the
"patch-queue" branch.

The tools I use the most to that hand are dom-apply-patches
(debian/patches/ -> patch-queue) and dom-save-patches (patch-queue ->
debian/patches/) from the dh-ocaml package which have been the initial
implementation of the work-flow. Nowadays however, the same idea has
been implemented and generalized in "gbp-pq", from git-buildpackage
itself. Unfortunately the doc is a bit scarce ATM and the manpage of
gbp-pq simply redirects to
https://honk.sigxcpu.org/piki/development/debian_packages_in_git/

If you like it, you can help out in improving the doc :-)

Hope this helps,
Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
 
Old 02-04-2010, 07:28 AM
sean finney
 
Default git and quilt

hi!

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

i use git+gbp+quilt in a number of my packages. i'm not convinced it's
necessarily the *best* system out there, but it keeps the overhead pretty
simple compared to using more complicated workflows la topgit, while
still meeting my own requirements for per-release branches etc.

i've heard that gbp has recently introduced some new tools for working
with patch queues, but i haven't had the time to look much more into them.
in the meantime i'm dropping the patches into a quilt series. backporting
upstream fixes is a bit nicer this way as well, as you can can do stuff
like "git show <commit> | quilt import -P upstream_<commit>.patch -"[1]


sean

[1] if there are conflicts it's a bit trickier, then i usually resolve
the cherry-pick, commit it, do the above for the resolved commit, and
rebase the resolved commit from the history.
 
Old 02-04-2010, 12:32 PM
Joachim Breitner
 
Default git and quilt

Hi,

Am Mittwoch, den 03.02.2010, 16:25 -0600 schrieb Matt Zagrabelny:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I found git-dpm <http://git-dpm.alioth.debian.org/> very nice.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
 
Old 02-04-2010, 03:57 PM
John Goerzen
 
Default git and quilt

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
> package.

I am doing the same, for the very simple reason that every other
approach I've seen violates the KISS (Keep It Simple, Stupid)
principle.

My Debian patches have two branches: master and upstream (some also
have a pristine-tar branch, but that is beside the point here.) I use
git-import-orig to load upstream, git merge to merge it into master,
and git-buildpackage to build my .debs.

It is easy, it is clean, and it works well. And it works like Git is
supposed to work.

I am not a fan of git-rebase due in part to the difficulty of working
with others, but also in part due to the difficulty of tracking how
your differences from upstream change over time. All the
debian/patches systems I have seen suffer from both of these flaws.

Consider, for instance, a git system in which debian/patches/* is
committed into git. OK, that's fine as it goes. The history of how
you "fixed upstream's frob from going all fubar" is in Git. But how
accessible is it? git blame frob.c is useless now, as the diff to
frob.c isn't in git. There is, in fact, no easy way to find out just
when a given change to frob.c was introduced or why (especially if
multiple debian/patches/* modified frob.c).

A git rebase workflow is slightly better on this, but only slightly.

For some non-Debian packages where I maintain a large number of diffs
against upstream, I use feature branches. Each feature branch can run
git merge upstream, and then the master branch merges all the FBs in.
(A couple of shell scripts automate this easily.)

Frankly I do see the utility of debian/patches for people that don't
use a VCS. But if your VCS already has very strong history analysis
features, which Git does, I see it as an unnecessary complication.

If someone reading this isn't familiar with Git's history features, I
would suggest you read manpages about:

git log --pickaxe or -S (details in gitdiffcore(7)

git blame (one of my very favorite git commands)

git diff -M -C --find-copies-harder
(git can be very intelligent about detecting copies and renames,
more than a debian/patch can reflect)
(these options also work for many other commands)

It all comes down to this: if I avoid debian/patches in my Git
packages, I get:

* A very simple and very fast workflow for routine maintenance

* Powerful history searching for when I need it

* An easily-accessible history of my changes to upstream, and
how they relate to upstream's changes. (How my diffs change over
time)

Looking at a diff of a diff is never easy or powerful, in my
experience. It is more of a bang your head on the keyboard sort of
experience.


-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-04-2010, 04:32 PM
"Bernhard R. Link"
 
Default git and quilt

* Matt Zagrabelny <mzagrabe@d.umn.edu> [100203 23:26]:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.
>
> I receive the following error from lintian and am looking for some
> guidance/best practices.
>
> % lintian --pedantic cdpr_2.3-3.dsc
> P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
> 1 more
>
> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
> package.

You could try http://git-dpm.alioth.debian.org/.

There are no packages for this yet, but that's no big harm as it is
only a single shell script.

Hochachtungsvoll,
Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 12:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org