On Saturday 16 August 2014 17:09:54 Raphael Hertzog wrote: > On Sat, 16 Aug 2014, Scott Kitterman wrote: > > Silly or not in your opinion, the Qt-KDE team repositories are set up this > > way. > > Sorry, I wasn't aware of that and didn't want to imply anything on people > using such a scheme. > > Still it would be interesting to know why the team made this choice and > what tools they are using to make this work. Anyone has pointers or can > explain us the choices made?
I'm writing this from a Kubuntu POV which should be close to debian-qt-kde as
we have a pretty close workflow (one of the reasons why we're talking about
moving our branches to their repositories) as we also only keep the debian/ dir
in the VCS.
a) Consistent VCS based packaging workflow
While upstream has switched most of their repositories to git, there's
a couple (artwork related) repositories that are kept in SVN, so if we would
use a git-based workflow with source and packaging together, we would have to
manage different workflows for specific packages within the same release which
is something I would prefer not to do.
b) Repository size
Cloning the upstream kdelibs repository is currently a ~158MiB
download, and while that might be one of the largest repositories, a KDE SC
release consists of ~170 tarballs so even leaving the SVN managed ones aside
you have to download *a lot*. It is a lot easier to work with a couple MiB
large packaging repositories that only manage the debian/ folder. (Add KDE
Frameworks 5 and Plasma5 and you've far surpassed the 200 package mark)
c) Upstream tag management
The KDE release team currently publishes tarballs with checksums and
git/svn revisions to packagers before the actual release for build testing and
early Q/A. So when we build the packages, there is no git tag yet that we could
use to generate a tarball ourselves, we would have to parse the tarball list
for the commit hash that was used to generate the tarball and base our
packaging on that - or wait for the tags and loose the chance to give the
release team pre-release feedback.
I might've missed something else, but those are some of our reasons for not
managing the source ourselves.
Both bzr builddeb and git buildpackage can download a tarball during the
package build in case the upstream source isn't already there (I usually rely
on watch files in the packages and deb-src entries in my apt configuration for
that)
Aside from the different workflow, I do like the tagging proposal with
vendor/version as that did not yet come up in my discussion with the
debian-qt-kde folks.
Philip
signature.asc
Description: This is a digitally signed message part.
