Enhancing 3.0 (git) source package format

[Johan Kiviniemi-6]

Hi,

It seems the current format of the 3.0 (git) style source packages
could be improved somewhat.

Currently, dpkg-source seems to create a tarball of the .git tree
under the working directory (with some exclusions).

This leads to the following issues:

• Git keeps unreferenced objects around in the local repository for a
while in case you want to undo an accidental deletion of e.g. a commit
or a branch. These deleted objects end up in the generated source
tarball (I checked).

• Git is good at creating an efficiently packed archive of objects. By
just creating a tarball of objects in whatever order they appear under
.git/objects and gzipping it, you lose the advantage of having e.g.
various revisions of the same file next to each other when
compressing. In addition, Git does delta encoding between file
revisions.

• Extra files, such as COMMIT_EDITMSG, hooks and config are added to
the source package. It appears this may be intentional, since they
aren’t excluded by dpkg-source -b, but should they *really* go into
the source package? Whenever your real Git repository is cloned, they
aren’t retained anyway.

In addition, dpkg-source explicitly has to make the hooks
non-executable for security reasons. Might as well not include them in
the first place in my *humble* opinion.

My proposal:

When building a source package, have dpkg-source run something like

git for-each-ref --format='%(refname)' | \
  grep -Ev '^refs/(remotes/|stash$)' | \
  xargs -d'\n' git bundle create ../PKG_VER.git-bundle HEAD

and reference PKG_VER.git-bundle directly from the dsc file.

The ‘git bundle’ command takes a list of refs (basically branches and
tags) and creates a file that contains a list of the refs and an
efficiently packed archive of the objects the refs (recursively) point
to.

No unreferenced objects or anything extraneous is added to the pack.
It contains exactly the data you’d receive when cloning the original
repository.

When unpacking the archive, have dpkg-source run

git clone PKG_VER.git-bundle PKG_VER

If a maintainer receives changes made by a contributor in this source
package format (say, by downloading a NMU from the archive), she can
simply ‘git fetch’ from the git-bundle file itself to her existing
repository and use exactly the same workflow she’d use if merging from
the contributor’s public repository over the network.

One sample doesn’t make a statistic, but here’s a quick comparison
using something I’m packaging at the moment:

132K    miniupnpd_1.4-0~local.git-bundle
196K    miniupnpd_1.4-0~local.git.tar.bz2
192K    miniupnpd_1.4-0~local.git.tar.gz
192K    miniupnpd_1.4-0~local.git.tar.lzma

Regards,
--
Jοhan Kiviniemi  http://johan.kiviniemi.name/


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

[Goswin von Brederlow-2]

Johan Kiviniemi <debian-dpkg-list@...> writes:

> Hi,
>
> It seems the current format of the 3.0 (git) style source packages
> could be improved somewhat.
>
> Currently, dpkg-source seems to create a tarball of the .git tree
> under the working directory (with some exclusions).
>
> This leads to the following issues:

Artifically bloated snapshots of the developers git repository in the
debian source that are 99.99% useless.

> • Git keeps unreferenced objects around in the local repository for a
> while in case you want to undo an accidental deletion of e.g. a commit
> or a branch. These deleted objects end up in the generated source
> tarball (I checked).
>
> • Git is good at creating an efficiently packed archive of objects. By
> just creating a tarball of objects in whatever order they appear under
> .git/objects and gzipping it, you lose the advantage of having e.g.
> various revisions of the same file next to each other when
> compressing. In addition, Git does delta encoding between file
> revisions.
>
> • Extra files, such as COMMIT_EDITMSG, hooks and config are added to
> the source package. It appears this may be intentional, since they
> aren’t excluded by dpkg-source -b, but should they *really* go into
> the source package? Whenever your real Git repository is cloned, they
> aren’t retained anyway.
>
> In addition, dpkg-source explicitly has to make the hooks
> non-executable for security reasons. Might as well not include them in
> the first place in my *humble* opinion.
>
> My proposal:

Remove 3.0 (qit) format completly. A full history bloats the source
and a cut down history has no advantage over a plain source.

It is far more usefull to put the url for the real git repository into
the control file. The number of people wanting to use git (instead of
just a snapshot of the source) but unable to git clone from the
internet is really miniscule and does not warrant the bloat for
everybody else.

Just my 2c,
        Goswin


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

[Raphael Hertzog-3]

On Fri, 30 Oct 2009, Johan Kiviniemi wrote:
> It seems the current format of the 3.0 (git) style source packages
> could be improved somewhat.

Updating/fixing that source package format is not a priority for me.
So if you want to see progress being made there, you should really submit
patches and not simply ideas. I will consider them, in particular
if they fix open bugs like: #477954, #534637

BTW, if you want to review/confirm the patch in #551829 it can also help.

> The ‘git bundle’ command takes a list of refs (basically branches and
> tags) and creates a file that contains a list of the refs and an
> efficiently packed archive of the objects the refs (recursively) point
> to.

It looks like a nicer approach than the current one, yes.

Cheers,
--
Raphaël Hertzog


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

[Tollef Fog Heen]

]] Goswin von Brederlow

| Remove 3.0 (qit) format completly. A full history bloats the source
| and a cut down history has no advantage over a plain source.

I think this would be a mistake.  I'm increasingly considering a full
git clone the source of my software (in the «preferred form of
modification») and so having dpkg able to natively consume and produce
that preferred form would be very useful.

| It is far more usefull to put the url for the real git repository into
| the control file. The number of people wanting to use git (instead of
| just a snapshot of the source) but unable to git clone from the
| internet is really miniscule and does not warrant the bloat for
| everybody else.

I don't see why you would do one or the otherrather than both?  Being
able to do git log and such on the result of an apt-get-ed package is
quite useful, without having to wait for a random upstream git
repository that might not be available.

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


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

[Goswin von Brederlow-2]

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

> ]] Goswin von Brederlow
>
> | Remove 3.0 (qit) format completly. A full history bloats the source
> | and a cut down history has no advantage over a plain source.
>
> I think this would be a mistake.  I'm increasingly considering a full
> git clone the source of my software (in the «preferred form of
> modification») and so having dpkg able to natively consume and produce
> that preferred form would be very useful.

Isn't your prefered form to git clone/uppdate/merge from the actual
repository used by the maintainer?

A copy of the maintainers repository as it was 2 years ago (think
stable) is not as usefull as a fresh clone.

> | It is far more usefull to put the url for the real git repository into
> | the control file. The number of people wanting to use git (instead of
> | just a snapshot of the source) but unable to git clone from the
> | internet is really miniscule and does not warrant the bloat for
> | everybody else.
>
> I don't see why you would do one or the otherrather than both?  Being
> able to do git log and such on the result of an apt-get-ed package is
> quite useful, without having to wait for a random upstream git
> repository that might not be available.

Is it? Do you actualy do that?

And we do have git.debian.org with high availability. It should not be
a random upstream git that might or might not be there. Make it a
reliable repository that will be there.

My feeling is that 3.0 (git) format adds bloat to the source packages
that hardly anyone ever uses, makes it that much harder for any
non-git user to edit the source and is of little extra value when the
maintainers git is month or years further along.

MfG
        Goswin


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

[Russ Allbery-2]

Goswin von Brederlow <goswin-v-b@...> writes:
> Tollef Fog Heen <tfheen@...> writes:

>> I think this would be a mistake.  I'm increasingly considering a full
>> git clone the source of my software (in the «preferred form of
>> modification») and so having dpkg able to natively consume and produce
>> that preferred form would be very useful.

> Isn't your prefered form to git clone/uppdate/merge from the actual
> repository used by the maintainer?

> A copy of the maintainers repository as it was 2 years ago (think
> stable) is not as usefull as a fresh clone.

It is when package maintainers orphan packages and rm -rf all their Git
repositories, such as just happened recently with a pile of Debian
packages.  If those packages had been 3.0 (git) packages, a new maintainer
would be in much better shape.

I would similarly like to use 3.0 (git) for all of my packages.  I think
it's the best direction going forward.  It avoids problems with Git
repositories disappearing, maybe being on only one server that loses a
hard drive, or otherwise becoming inaccessible, and provided that the
package includes just the compressed repository and not a checkout, the
additional space consumption is minimal.  The source packages may actually
be smaller if we used something like pristine-tar to handle the upstream
orig.tar.gz file.

>> I don't see why you would do one or the otherrather than both?  Being
>> able to do git log and such on the result of an apt-get-ed package is
>> quite useful, without having to wait for a random upstream git
>> repository that might not be available.

> Is it? Do you actualy do that?

I don't know because there aren't any 3.0 (git) packages.  I would.

> And we do have git.debian.org with high availability. It should not be a
> random upstream git that might or might not be there. Make it a reliable
> repository that will be there.

Not everyone wants to host all Git repositories for their Debian packages
on git.debian.org.  I don't, for instance; for many of them, I want to
host the Debian packaging in a branch on the same repository used for
upstream development.

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


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

[Joey Hess]

I support changing 3.0 (git) to use a bundle. Besides closing the bugs
mentioned in this thread, a bundle consists of a simple header + a standard
git pack. Since git packs are used as a wire format, this provides better
assurance that future versions of git will retain compatability with
the source packages. Also, being able to directly clone a bundle file
is a great feature.

The only thing I would miss from this version of the format is that when
unpacked, it would not include remotes information, and so remotes would need
to be manually added if you wanted to 'git pull' to get newer commits etc. I
suppose that the remotes info could be added into the source format in some
other way however.

Johan Kiviniemi wrote:
> git for-each-ref --format='%(refname)' | \
>  grep -Ev '^refs/(remotes/|stash$)' | \
>  xargs -d'\n' git bundle create ../PKG_VER.git-bundle HEAD

You forgot to drop bisect refs. Also, if there are a *lot* of refs, xargs may
run git-bundle repeatedly; subsequent runs will happily overwrite the bundle.
So I suggest:

git bundle create ../bundle $(git for-each-ref --format='%(refname)' | egrep -v '^refs/(remotes/|bisect/|stash$)')

This still has the potential problem of failing if there are >20kb worth of
ref information. Probably the right fix for that limit is to patch git-bundle
so it can read the refs from stdin, as git-pack-objects already does.

Russ Allbery wrote:
> It is when package maintainers orphan packages and rm -rf all their Git
> repositories, such as just happened recently with a pile of Debian
> packages.  If those packages had been 3.0 (git) packages, a new maintainer
> would be in much better shape.

Even when package orphaners are careful to preserve their git repos,
it can be easy for them to be dropped in transition to the new maintainer.
(See for example: uqm.)

--
see shy jo

[Raphael Hertzog-3]

On Wed, 04 Nov 2009, Russ Allbery wrote:
> Not everyone wants to host all Git repositories for their Debian packages
> on git.debian.org.  I don't, for instance; for many of them, I want to
> host the Debian packaging in a branch on the same repository used for
> upstream development.

I certainly hope that the upstream repository will not be deleted...
For other cases, you must know that we host simple mirrors of git
repositories on git.debian.org (and they are backupped with the others).

One example, you can see more on the front page listing:
http://git.debian.org/?p=mirror/wanna-build.git;a=summary

Cheers,
--
Raphaël Hertzog


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

[Tollef Fog Heen]

]] Joey Hess

| I support changing 3.0 (git) to use a bundle. Besides closing the bugs
| mentioned in this thread, a bundle consists of a simple header + a
| standard git pack. Since git packs are used as a wire format, this
| provides better assurance that future versions of git will retain
| compatability with the source packages. Also, being able to directly
| clone a bundle file is a great feature.

Just to be sure: Bundles can include multiple branches, tags and all,
right?

| The only thing I would miss from this version of the format is that
| when unpacked, it would not include remotes information, and so
| remotes would need to be manually added if you wanted to 'git pull' to
| get newer commits etc. I suppose that the remotes info could be added
| into the source format in some other way however.

Either getting upstream to extend the format to allow remotes to be
included or extending the source package format sounds like a good idea.

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


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

[Tollef Fog Heen]

]] Goswin von Brederlow

| Tollef Fog Heen <tfheen@...> writes:
|
| > ]] Goswin von Brederlow
| >
| > | Remove 3.0 (qit) format completly. A full history bloats the source
| > | and a cut down history has no advantage over a plain source.
| >
| > I think this would be a mistake.  I'm increasingly considering a full
| > git clone the source of my software (in the «preferred form of
| > modification») and so having dpkg able to natively consume and produce
| > that preferred form would be very useful.
|
| Isn't your prefered form to git clone/uppdate/merge from the actual
| repository used by the maintainer?

Not for that particular copy of the software, no.

It would be like saying that foo-1.0.tar.gz is not the preferred form of
modification since there is a foo-2.0.tar.gz out and upstream won't take
patches to 1.0 because it's dead.

| A copy of the maintainers repository as it was 2 years ago (think
| stable) is not as usefull as a fresh clone.

That depends on whether I want to fix something in the copy that is 2
years old and which is in stable, or if I want to do upstream
development.  Quite often, the former is the case.

| > I don't see why you would do one or the other rather than both?
| > Being able to do git log and such on the result of an apt-get-ed
| > package is quite useful, without having to wait for a random
| > upstream git repository that might not be available.
|
| Is it? Do you actualy do that?

Yes.

| And we do have git.debian.org with high availability. It should not be
| a random upstream git that might or might not be there. Make it a
| reliable repository that will be there.

Whether git.d.o is up or not does not help me if I'm at the end of tiny
link.  Also, if we go with my claim that source (in the «preferred form
for modification» sense) includes history, it means you need to ship the
history somehow.  Saying «it's on git.d.o» doesn't help you then.  The
suggestion to use a bundle would probably be a good enough start.  I'd
like to be able to just apt-get source foo ; cd foo-* ; git log though,
but having to git clone the bundle is something I guess I can live with.

| My feeling is that 3.0 (git) format adds bloat to the source packages
| that hardly anyone ever uses, makes it that much harder for any
| non-git user to edit the source and is of little extra value when the
| maintainers git is month or years further along.

Even if the upstream VCS has moved on, you save a bit of bandwidth by
having something that comes with half the history, even if you don't
have all of it.

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


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

[Goswin von Brederlow-2]

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

> ]] Goswin von Brederlow
> | My feeling is that 3.0 (git) format adds bloat to the source packages
> | that hardly anyone ever uses, makes it that much harder for any
> | non-git user to edit the source and is of little extra value when the
> | maintainers git is month or years further along.
>
> Even if the upstream VCS has moved on, you save a bit of bandwidth by
> having something that comes with half the history, even if you don't
> have all of it.

Weigh that against the bandwidth spend for mirrors and for people that
do not need or want the history and the extra cost in terms of needing
more CD/DVD images to contain a source snapshot. Also the cost for
snapshot.debian.org having to have the extra bloat for every single
version uploaded. For a worst case take linux-2.6 as example.

Also why would you download the source package in the first place if
what you really want is a git checkout. The extra bandwidth for a git
checkout would only be as much as the 3.0 (git) format would lack in
history.

For me a debian source package is a snapshot of a particular version
of the source that exactly coresponds to the binary packages build
from it. For history there is the changelog, old source packages on
snapshot.debian.org (soon again) and cvs/svn/hg/git/arch repositories.

My expectation is also that I can "apt-get source foo", edit some
files and debuild without having to learn a new tool and completly
foreign workflow. The various patch systems used with 1.0 packages
destroy that somewhat but 3.0 (quilt) restores that feature again. 3.0
(git) on the other hand goes in the wrong direction as it makes the
package even more special.


But in the end it comes down to taste I guess. Do you want to force
people to use git or are you friendly to those that don't use it?
So I will shut up now before we go around the circle again.

MfG
        Goswin


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

[Jonathan Nieder]

Goswin von Brederlow wrote:

> Weigh that against the bandwidth spend for mirrors and for people that
> do not need or want the history and the extra cost in terms of needing
> more CD/DVD images to contain a source snapshot. Also the cost for
> snapshot.debian.org having to have the extra bloat for every single
> version uploaded. For a worst case take linux-2.6 as example.

Your other points made a lot of sense to me, but this one seems more
intriguing.

Could snapshot.debian.org learn to keep just the objects in each
release that are not in the previous one?  This is a genuine question:
I am not sure how difficult the pristine-tar-like magic would be to
get the md5 to match the archive for each source package.

Jonathan


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

[Russ Allbery-2]

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

> ]] Joey Hess

> | I support changing 3.0 (git) to use a bundle. Besides closing the bugs
> | mentioned in this thread, a bundle consists of a simple header + a
> | standard git pack. Since git packs are used as a wire format, this
> | provides better assurance that future versions of git will retain
> | compatability with the source packages. Also, being able to directly
> | clone a bundle file is a great feature.

> Just to be sure: Bundles can include multiple branches, tags and all,
> right?

Yup!  They're quite nice.  I only discovered them recently, but they're
also fantastic for sharing pending security patches that cannot yet be
publicly disclosed among the co-maintainers of a package.

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


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

[Russ Allbery-2]

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

> Whether git.d.o is up or not does not help me if I'm at the end of tiny
> link.  Also, if we go with my claim that source (in the «preferred form
> for modification» sense) includes history, it means you need to ship the
> history somehow.  Saying «it's on git.d.o» doesn't help you then.  The
> suggestion to use a bundle would probably be a good enough start.  I'd
> like to be able to just apt-get source foo ; cd foo-* ; git log though,
> but having to git clone the bundle is something I guess I can live with.

I think a full implementation of a 3.0 (git) format that uses bundles
would include support in dpkg-source, so that when you unpack a 3.0 (git)
package (such as with apt-get source), dpkg-source would take care of
setting up the Git repository from the bundle for you.  This is similar to
how dpkg-source handles applying patches in 3.0 (quilt) packages.

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


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

[Tollef Fog Heen]

]] Goswin von Brederlow

| Tollef Fog Heen <tfheen@...> writes:
|
| > ]] Goswin von Brederlow
| > | My feeling is that 3.0 (git) format adds bloat to the source packages
| > | that hardly anyone ever uses, makes it that much harder for any
| > | non-git user to edit the source and is of little extra value when the
| > | maintainers git is month or years further along.
| >
| > Even if the upstream VCS has moved on, you save a bit of bandwidth by
| > having something that comes with half the history, even if you don't
| > have all of it.
|
| Weigh that against the bandwidth spend for mirrors and for people that
| do not need or want the history and the extra cost in terms of needing
| more CD/DVD images to contain a source snapshot. Also the cost for
| snapshot.debian.org having to have the extra bloat for every single
| version uploaded. For a worst case take linux-2.6 as example.

If we (as I do) consider history part of the source, that size increase
is irrelevant.

| Also why would you download the source package in the first place if
| what you really want is a git checkout. The extra bandwidth for a git
| checkout would only be as much as the 3.0 (git) format would lack in
| history.

Because I want to add a patch that changes a behaviour in a stable
package, and I want to add that patch in a way that gives me the least
work, both when writing it, but also when bringing it forward.  Also, my
mirror might be local; git.d.o and random upstream repositories
certainly are not.

| My expectation is also that I can "apt-get source foo", edit some
| files and debuild without having to learn a new tool and completly
| foreign workflow. The various patch systems used with 1.0 packages
| destroy that somewhat but 3.0 (quilt) restores that feature again. 3.0
| (git) on the other hand goes in the wrong direction as it makes the
| package even more special.

I'm trying to come up with a reasonable workflow rather than getting
entangled in what intricasies of the different source package formats.
At the moment, what I want is best done with a bundle in debian/ and a
3.0 (native) package and a README.source.

| But in the end it comes down to taste I guess. Do you want to force
| people to use git or are you friendly to those that don't use it?
| So I will shut up now before we go around the circle again.

I don't see why you think «ship the history with the package» (which is
what I want to do) implies that you can't do apt-get source foo ; cd
foo-* ; hack.

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


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

[Felipe Sateler]

On Sun, 2009-11-08 at 22:44 +0100, Tollef Fog Heen wrote:

> ]] Goswin von Brederlow
>
> | Tollef Fog Heen <tfheen@...> writes:
> |
> | > ]] Goswin von Brederlow
> | > | My feeling is that 3.0 (git) format adds bloat to the source packages
> | > | that hardly anyone ever uses, makes it that much harder for any
> | > | non-git user to edit the source and is of little extra value when the
> | > | maintainers git is month or years further along.
> | >
> | > Even if the upstream VCS has moved on, you save a bit of bandwidth by
> | > having something that comes with half the history, even if you don't
> | > have all of it.
> |
> | Weigh that against the bandwidth spend for mirrors and for people that
> | do not need or want the history and the extra cost in terms of needing
> | more CD/DVD images to contain a source snapshot. Also the cost for
> | snapshot.debian.org having to have the extra bloat for every single
> | version uploaded. For a worst case take linux-2.6 as example.
>
> If we (as I do) consider history part of the source, that size increase
> is irrelevant.
>
> | Also why would you download the source package in the first place if
> | what you really want is a git checkout. The extra bandwidth for a git
> | checkout would only be as much as the 3.0 (git) format would lack in
> | history.
>
> Because I want to add a patch that changes a behaviour in a stable
> package, and I want to add that patch in a way that gives me the least
> work, both when writing it, but also when bringing it forward.  Also, my
> mirror might be local; git.d.o and random upstream repositories
> certainly are not.

It's possible to specify a (signed) tag somewhere. You don't need a
separate blurb for very release.



--
Saludos,
Felipe Sateler



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

[Goswin von Brederlow-2]

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

> ]] Goswin von Brederlow
>
> | Tollef Fog Heen <tfheen@...> writes:
> |
> | > ]] Goswin von Brederlow
> | > | My feeling is that 3.0 (git) format adds bloat to the source packages
> | > | that hardly anyone ever uses, makes it that much harder for any
> | > | non-git user to edit the source and is of little extra value when the
> | > | maintainers git is month or years further along.
> | >
> | > Even if the upstream VCS has moved on, you save a bit of bandwidth by
> | > having something that comes with half the history, even if you don't
> | > have all of it.
> |
> | Weigh that against the bandwidth spend for mirrors and for people that
> | do not need or want the history and the extra cost in terms of needing
> | more CD/DVD images to contain a source snapshot. Also the cost for
> | snapshot.debian.org having to have the extra bloat for every single
> | version uploaded. For a worst case take linux-2.6 as example.
>
> If we (as I do) consider history part of the source, that size increase
> is irrelevant.
>
> | Also why would you download the source package in the first place if
> | what you really want is a git checkout. The extra bandwidth for a git
> | checkout would only be as much as the 3.0 (git) format would lack in
> | history.
>
> Because I want to add a patch that changes a behaviour in a stable
> package, and I want to add that patch in a way that gives me the least
> work, both when writing it, but also when bringing it forward.  Also, my
> mirror might be local; git.d.o and random upstream repositories
> certainly are not.
>
> | My expectation is also that I can "apt-get source foo", edit some
> | files and debuild without having to learn a new tool and completly
> | foreign workflow. The various patch systems used with 1.0 packages
> | destroy that somewhat but 3.0 (quilt) restores that feature again. 3.0
> | (git) on the other hand goes in the wrong direction as it makes the
> | package even more special.
>
> I'm trying to come up with a reasonable workflow rather than getting
> entangled in what intricasies of the different source package formats.
> At the moment, what I want is best done with a bundle in debian/ and a
> 3.0 (native) package and a README.source.
>
> | But in the end it comes down to taste I guess. Do you want to force
> | people to use git or are you friendly to those that don't use it?
> | So I will shut up now before we go around the circle again.
>
> I don't see why you think «ship the history with the package» (which is
> what I want to do) implies that you can't do apt-get source foo ; cd
> foo-* ; hack.

It currently implies that. The 3.0 (git) format, last I tried, is not
transparent to the user like 3.0 (quilt) is.

I'm not saying it can't be made equaliy transparent but you will have
your work cut out there.

MfG
        Goswin


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