¡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 <[email protected]> And Ubuntu packages use: Maintainer: Kubuntu Developers <[email protected]> XSBC-Original-Maintainer: Debian Qt/KDE Maintainers <[email protected]> The merged packages use: Maintainer: Debian/Ubuntu Qt/KDE Maintainers <[email protected]> X-Ubuntu-Maintainer: Kubuntu Developers <[email protected]> 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 /\/\ /\ >< `/
signature.asc
Description: Digital signature
-- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
