Re: No native packages?
On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
> Tollef Fog Heen <tfheen@err.no> writes:
> > ]] Gergely Nagy
>
> >> No, not really. I don't really care what tools one uses, as long as the
> >> result is reasonably easy *and* reliable to work with. Since VCS can be
> >> stale, and quite often does not include neither NMUs, nor backports,
> >> that fails the reliable requirement.
>
> > It sounds like you are arguing that we should just ship the the
> > repository in the source package, then. No chance of it ever getting
> > out of date, trivial to find the merge points and missing patches
> > between two packages and fits much better with a VCS-driven workflow.
>
> Yes, many of us would like that, which is why it's been repeatedly
> discussed at Debconfs, but no one has come up with a good solution to the
> fact that this requires reviewing the entire VCS archive for DFSG-freeness
> and rewriting history if any non-free code is ever introduced in it. (Or,
> well, changing the requirements we have around source package freeness,
> but that seems less likely.)
Maybe I forgot the answer, but at least in terms of git and the dpkg
3.0 (git) format, why can't we simply make use of shallow cloning? We
only distribute a single revision, the one we're building, and if the
history is polluted for whatever reason, it has no impact--we're only
providing the equivalent of a tarball. The difference being, there's
nothing preventing anyone receiving the package from adding the
appropriate remotes and restoring the full history (at their choice),
so it retains its utility. From the POV of review, it's then no
different to a plain tarball. But from the POV of a developer, I can
fetch the history, add remotes, commit changes, push to somewhere and
open pull requests, etc..
At least for schroot, both the source and release are all in git, so
making the release tarball is nowadays a single "git archive". Having the
ability to use 3.0 (git) would allow the use of a git workflow throughout
with zero intermediately formats like tar.
To get more back on topic, all the packages I maintain in Debian are
non-native. It's more flexible, and it encourages separation of "upstream"
and "debian" releases, even when Debian /is/ the upstream. So changes to
the actual package content go into proper "upstream" releases, and you
have the option to make as many Debian revisions as necessary. It makes
things easier for derivatives and external users. I don't think there's
any real difference in the amount of effort it takes to do non-native
releases, and I can't see any compelling reason for "native" releases
other than history.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: