Re: Enhancing 3.0 (git) source package format
Tollef Fog Heen <tfheen@err.no> writes:
> ]] Goswin von Brederlow
>
> | Tollef Fog Heen <tfheen@err.no> 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
Reply to: