RFC: Moving kubuntu packaging branches to pkg-kde git

[Maximiliano Curia]

¡Hola Rohan!

El 2014-07-29 a las 16:10 +0200, Rohan Garg escribió:
> > - master: has the shared packaging and targets the latest upstream (beta?)
> > release (which should really be everything as long as something doesn't cause
> > a problem for the other team)

> > - <series> (e.g. unstable, utopic): has any distribution specific changes that
> > cannot be kept in master (like specific patches, recommends/suggests changes
> > for archive reasons)
> > and is used to generate the actual archive packages for that specific series.

This is mostly ok, but, as I mentioned via irc, I think it would be better to
split branches only when there is a packaging difference, and it should be a
goal to minimize these.

Right now, we have merged some bzr history for simple packages, mostly
uneventful, some of the things that we need to solve are:

 - debian/control Maintainer field

 Right now Debian packages use:
  Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>
 And Ubuntu packages use:
  Maintainer: Kubuntu Developers <kubuntu-devel at lists.ubuntu.com>
  XSBC-Original-Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>
 The merged packages use:
  Maintainer: Debian/Ubuntu Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>
  X-Ubuntu-Maintainer: Kubuntu Developers <kubuntu-devel at lists.ubuntu.com>

 There is a proposal of ScottK to use a debian/control.in to generate the
 right fields on each case (using the version vendor was it?), I would
 prefer to set some Maintainer string we can live with and avoid
 regenerating the debian/control file on build.

 - Bumping build dependencies versions

 Kubuntu packages force the rebuild of the kde packages against the newer
 versions of the libs it uses, even if upstream doesn't require them and/or
 there is no abi/api change between them, while in Debian we try to bump the
 build dependencies because the upstream CMakeLists.txt declares that it needs
 the newer version or to upload the package in a way that waits for a
 transition to happend.

 The Kubuntu solution could end up hiding some abi breakage, which, in Debian,
 we would prefer to expose.

 - Updating packages without source changes

 On each kde release there are a number of packages that have no changes
 upstream, in Debian we skip those packages.

 Again, problems with these packages would expose an abi breakage.

> > While I believe that this mostly should work fine, at this point I'm not quite
> > sure how to manage the changelog. OdyX suggested generating it from the git
> > commit messages which I think would work out best, as we could then keep our
> > respective distribution changelogs and only share the change messages.

As mentioned via irc, the changelogs can be merged (dpkg-mergechangelogs can
be useful here), keeping in mind that the first upload of an upstream version
to a particular distribution requires a full upload, so we'll need to use an
explicit '-sa' to upload an upstream version that the other distribution have
already uploaded.

> > For now, I would propose trying this shared repository idea out with the new
> > kf5 and later also the plasma packages as you don't have any repositories for
> > those yet.

> Could we move this forward maybe? :D

Yes, I believe this is the right way.

-- 
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are–by
definition–not smart enough to debug it.”
-- Brian Kernighan
Saludos /\/\ /\ >< `/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20140807/0bbd2573/attachment.sig>