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-2008, 12:32 AM
Darren Salt
 
Default How to cope with patches sanely (Was: State of the project - input needed)

I demand that I definitely did write...

[snip]
> Whatever DSCM is used, it needs history truncation. This rules out
> mercurial (at present? certainly 0.9.5); I tarred up the bits needed to
> recreate a checked-out repository of xine-lib - 8.6MB orig.tar.gz
> (1.1.9.1), 28MB hg.tar.gz (tip, but the changes since 1.1.9.1 don't amount
> to much).

... or 10.4MB for current xine-lib-deb.

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Travel less. Share transport more. PRODUCE LESS CARBON DIOXIDE.

Generosity and perfection are your everlasting goals.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-03-2008, 07:14 AM
Andreas Tille
 
Default How to cope with patches sanely (Was: State of the project - input needed)

On Sat, 2 Feb 2008, martin f krafft wrote:


PS: this figure is 80% correct but will surely be questioned by 70%
of the people. The likelihood that someone replies to this message
is 50%.


I just take the mere chance to do this. ;-)


The likelihood that someone flames is currently 12.6%.


Is this number related to the 50% answers or absolute?


The likelihood that I err is 0.


I like this. ;-)

I also like the feeling when sun might have risen behind the mountains
in high North

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-03-2008, 08:15 AM
Pierre Habouzit
 
Default How to cope with patches sanely (Was: State of the project - input needed)

On Sat, Feb 02, 2008 at 08:21:44AM +0000, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@debian.org> [2008.01.27.0505 +1100]:
> > Seconded. I'd add, that in fact we should standardize on quilt
> > as an exchange format for patches, because it's simple, and that
> > there are powerful tools to handle them.
>
> Except those patches contain no VCS-specific data, like the author.
> In relation to licencing issues, I think it's especially interesting
> to have the ability to cherry-pick and keep the original committer
> info unchanged. I'd say what we really want is a way to cherry-pick
> between different VCS, and a higher-level wrapper on top of all VCS
> implementing a generic, cross-distro workflow.

FWIW I export my patches in an almost quilt compatible way (ls -1 >
series and that would be true), using git format-patch, hence retaining
VCS informations.

Using quilt as an exchange format doesn't mean that you should strip
off VCS metadatas (for the clever ones that supports it). Git works the
same with a series of patches with authoring information. That's carved
into its design.

--
O Pierre Habouzit
O madcoder@debian.org
OOO http://www.madism.org
 
Old 02-03-2008, 08:38 AM
Pierre Habouzit
 
Default How to cope with patches sanely (Was: State of the project - input needed)

On Sat, Feb 02, 2008 at 08:38:14AM +0000, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@debian.org> [2008.01.27.0939 +1100]:
> > On Fri, Jan 25, 2008 at 06:00:02PM +0000, Raphael Hertzog wrote:
> > > On Fri, 25 Jan 2008, Michael Banck wrote:
> > > > On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> > > > > On 25/01/08 at 08:01 +0000, Steve Langasek wrote:
> > > > > > As a second runner up, quilt is ok by me.
>
> ...
>
> > I'm less and less sure that a git-based format is a brilliant
> > idea. I like git more than a lot, but it's a poor idea to base
> > source packages on them.
>
> Why?

Because it's a way to high level tool for the task. Git (and I suppose
that the following is true for other DVCS, and if not, they _REALLY_
suck, and I mean it, really) has been designed so that you can only
exchange patches. That means that you can work on your git repository,
extract your patches, send them upstream, see upstream merge them into
his git repository and when you fetch back, git figures things out.
*DANG* that's how the kernel and git itself are developed.

There is no *need* to force people using git to grok the format since
git *is* able to grok it (not the current one, but some form of wig&pen
should probably work).

> > IOW, all that you should need to grok what is in a source package
> > should basically be tar/ar/cpio/... and vi.
>
> Are you sure that this has to be the case in 10 years?

Are you sure git will be there and backward compatible in 10 years ?
Okay, it's likely given the current upstream, that focuses a _lot_ on
backward compatibility. But still. Some repository formats have been
deprecated (the object store is of version3 and IIRC git doesn't grok
version1 anymore, but I may be mistaken). That's the kind of gamble I
wouldn't take.

Whereas I guess tar will always grok tarballs it generates today in 10
years, and gzip/bzip2/lzma/$compressor won't change either, and text is
text for enough time to assume it'll remain as editeable in 10 years.

> At the same time, I don't think it's wise to expect people to know
> the different ways to handle git.tar.gz and bzr.tar.gz and so on.
> I think what we want is the often-mentioned wrapper which hides the
> actual storage backend in use.

No IMSHO we want the tools we use to be able to import informations
from these packages easily, and in fact, we rather just want them to
generate those packages. I see little point in .git.tar.gz because it
only holds _recent_ history, and you can't base new devels on it (you
cannot commit in a shallow clone in git). AFAUI in bzr it's even worse:
shallow clones have a reference to the original repository, that could
have disappeared in 10 years. So it makes this extra history usefulness
quite useless in the long term [I'm not saying it's a waste of space or
whatever, I just say it's IMHO a not so useful feature, which adds a
clear complexity and non-editability to the package].

On Sat, Feb 02, 2008 at 08:43:12AM +0000, martin f krafft wrote:
> also sprach Theodore Tso <tytso@mit.edu> [2008.01.28.1613 +1100]:
> > From: Author O' The Patch <author@example.com>
> > Detailed patch description
> > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> >
> > This is at the beginning of every single quilt patch, and because of
> > this, we can easily important the patch into either a mercurial or git
> > repository, while preserving the authorship information of the patch.
>
> Nice, I didn't see this before. This *is* in fact nice and puts
> the quilt *format* very high on my list.

Yes, quilt preserves *everything* you put in the header, so if you use
git (or $scm) to generate the patches with authoring information, commit
message and so on, it wont be lost.

You agree on the fact that a Debian source package isn't (or shouldn't
for big enough packages) be the preferred form of modification. Then
it's that it's an exchange format. As an exchange format quilt is
brilliant, because it holds *EVERYTHING* a SCM need to figure out how to
rebuild meregeable and rebaseable patches from it. So why bother with
anything else ?

An exchange format *Must* be simple. That's the very reason why Debian
uses rfc822-style flat files everywhere, and that's one of our best
strength:
(1) this format is ubiquitous in Debian ;
(2) it's really easy to parse (in the Debian flavour that doesn't need
the stupid quoted-printeable escapings and so on at least) ;
(3) it's human readable ;
(4) implementing parsers and generators take usually less than a
hundred lines in a high level enough language.

.git.tar.gz fails in those 4 points.

What I ask you is just to be consistent. Either we _will_ modify
source packages, either we won't. If we will, adding features to it is a
good idea, if we won't, let's just focus on how to let it be expressive
enough to encode in it all what we use as new features upstream from it.
And as a matter of a fact, quilt is enough for that.


--
O Pierre Habouzit
O madcoder@debian.org
OOO http://www.madism.org
 

Thread Tools




All times are GMT. The time now is 03:17 AM.

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