On Sat, Feb 02, 2008 at 08:38:14AM +0000, martin f krafft wrote: > also sprach Pierre Habouzit <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [2008.01.28.1613 +1100]:
> > From: Author O' The Patch <[EMAIL PROTECTED]>
> > Detailed patch description
> > Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
> >
> > 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 [EMAIL PROTECTED]
OOO http://www.madism.org
pgpRjYFihpb3z.pgp
Description: PGP signature
