On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote: > > On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote: > > > As an example: to update to a new upstream release, I ideally just have > > to drop the new upstream tarball, update d/changelog and am done. > > Compare with [1] which is much more complicated, even ignoring the extra > > complexity using dgit adds compared to just using git. > > > > [1] > > https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES > > As a package maintainer, if you don't keep the whole source package in > git, you're giving up on a lot of the power of git.
I think keeping entry barriers low is more important than being able to use all the power of Git. That's sadly one of the main problems with Dgit: it raises entry barriers by making packaging more complicated. Packaging shouldn't be complicated: it's just a build recipe plus some metadata. > The most > significant thing is that you cannot manipulate quilt patches as commits > on a branch. It is also much more involved to cherry pick commits from > upstream branches, and quickly obtain diffs between Debian's version of > the code and arbitrary other branches, to mention a few other things. Most packages don't need that either: for me most changes are either fairly static (no merge conflict) or are just backports of upstream commits (in which case they can just be removed when using a new upstream version). It does get easier when most fixes are applied upstream instead of staying only in Debian :-) > I also think that you're doing a disservice to downstream users. If > you're trying to fix a bug in the packaged version of some software on > your computer, you don't care about the distinction between Debian's > packaging scripts and the upstream code. Either the bug is in upstream code, then you just need the upstream source (and the patch should be pushed upstream anyway). Or it is in the (ideally smalll) Debian-specific parts which hopefully don't need a long history to understand. If you have large, invasive changes from upstream, you effectively fork the package. Maybe one should release it as a "fork" then so non- Debian distributions can benefit from the changes in the fork. That is arguable a disservice to users... Ansgar
