Hello, On antradienis 13 Liepa 2010 01:12:03 Mark Purcell wrote: > Seems like a lot of options and moving parts for the maintenance of > kde-extras packages. > > In kde-extras we generally have new upstream releases with sometimes a > handful of Debian specific patches, sometimes pulling something early from > upstream.
Well, my original mail has never been about kde-extras. Unlike qt4-x11 or KDE, kde-extras are released individually as separate rather small entities. Compare that to 400+ mb big qt4-x11 or 22 huge source packages of KDE. If I was to start packaging kde-extras app from scratch, I would definitely choose the same workflow I currently use for ktorrent/konversation, i.e. upstream + packaging with patching in quilt + pristine-tar. upstream branches are really useful when they are manageable despite some caveats with quilt patches in this workflow (the next release of dpkg-dev will make it easy to workaround them). However, this 'upstream branch' workflow does not scale in cases like qt4-x11 (due to its size) or official KDE modules (due to the number of upstream branches to update for each new release and their cumulative size). "upstream + packaging with patching in quilt + pristine-tar" is basically what git buildpackage supports. At least, git import-orig makes it easy to import and manage upstream & pristine-tar branches. However, I do not agree with `git buildpackage` tagging conventions (e.g. that it replaces '~', which git does not support in tags, with '.', how uninformative tag annotations are etc.) so I tend to avoid it. > svn-buildpackage manages this use case without lots of command line foo, > without manual extraction of the upstream tarball or manually extracting > the tarball into the repository. > Am I missing something, or is git too powerful for the use case we have > with kde-extras? I have never used svn-buildpackage but I believe git-buildpackage is as easy to use as svn-buildpackage if you want to use a wrapper and accept all its conventions (which I don't). That qt4-x11.git README.source was written with bare git in mind so it might be a bit verbose. -- Modestas Vainius <modes...@vainius.eu>
Description: This is a digitally signed message part.