Salut! Since, I think, this is the first time I write to this list, I suppose a introduction is kind of appropriate :) My name is Harald Sitter and I am a Kubuntu dev from Austria [1] and I am working on everything but really nothing. Anyway... I was wondering what you people think about getting akondiconsole out of the kdepim-runtime (4.3) package. Currently kdepim-runtime is a single package (+ -dbg), yet akonadiconsole is a development tool (it even tells so upon startup), so it is probably not desirable to have it installed as part of the main KDE(Pim) stack. The options to get it out of there: 1) In Kubuntu the package is split into -runtime, -runtime-data and -runtime-dev, so eventually Debian should adopt that and move akondiconsole to the -dev package 2) Split akonadiconsole into its own package 3) Split only the akonadiconsole binary in its own package and patch the desktop file to use TryExec I personally prefer option 2 since -dev should only contain binaries that are actually needed for building software (e.g. what can be found in kdelibs5-dev). Option 3 would only make sense if the app had loads of arch independent data (IMHO), which is not the case. Opinions? [1] https://launchpad.net/~apachelogger regards, Harald
Hello, On ketvirtadienis 23 Liepa 2009 00:00:41 Harald Sitter wrote:> The options to get it out of there: > 1) In Kubuntu the package is split into -runtime, -runtime-data and > -runtime-dev, so eventually Debian should adopt that and move > akondiconsole to the -dev packageWe will not split off -data as long as it basically contains *.desktop files and is around ~40 kb in size (multiarch is still not here). *-runtime-dev does not make sense by definition.> 2) Split akonadiconsole into its own packageMaybe we could ask upstream to move it to back kdepim(libs)? Debugging tools do not really belong to -runtime packages, do they? In my opinion, if to split off akonadiconsole, then invent another package name like kdepim-runtime-dev- tools (similar to qt4-dev-tools) or something.> 3) Split only the akonadiconsole binary in its own package and patch > the desktop file to use TryExecWhy would we need to patch desktop file? We typically ship desktop file in the same package as the binary to avoid dangling desktop files.> I personally prefer option 2 since -dev should only contain binaries > that are actually needed for building software (e.g. what can be found > in kdelibs5-dev).Yeah, *-runtime-dev name would be confusing. However, I don''t think akonadiconsole is so important to get a package of its own. A package where all such devel tools could be put (in the future) is more appropriate. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090723/976acfc1/attachment.pgp>
Op Wednesday 22 July 2009 23:32 schreef u:> > 2) Split akonadiconsole into its own package > > Maybe we could ask upstream to move it to back kdepim(libs)? Debugging tools > do not really belong to -runtime packages, do they? In my opinion, if to split > off akonadiconsole, then invent another package name like kdepim-runtime-dev- > tools (similar to qt4-dev-tools) or something.We can not move it to kdepimlibs as it depends on kdepim-runtime. Depending on -runtime at build time, kind of defeats the purpose ;-).
On Wednesday, 2009-07-22, Tom Albers wrote:> Op Wednesday 22 July 2009 23:32 schreef u: > > > 2) Split akonadiconsole into its own package > > > > Maybe we could ask upstream to move it to back kdepim(libs)? Debugging > > tools do not really belong to -runtime packages, do they? In my opinion, > > if to split off akonadiconsole, then invent another package name like > > kdepim-runtime-dev- tools (similar to qt4-dev-tools) or something. > > We can not move it to kdepimlibs as it depends on kdepim-runtime. Depending > on -runtime at build time, kind of defeats the purpose ;-).At least not for now. AFAIK the plan is to move it out to kdepim once the dependency issues are resolved, e.g. libraries currently in kdepim-runtime become public API and move to kdepimlibs. I would recommend to leave it in kdepim-runtime for now, also because it is a really helpful for diagnosing Akonadi setup related problems. Akonadi is currently mainly interesting for users which want to try new technologies, e.g. for testing purposes, and at this point they can give more valuable feedback when having access to akonadiconsole. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090723/2b368f46/attachment.pgp>
On Thu, Jul 23, 2009 at 12:29 PM, Kevin Krammer<kevin.krammer at gmx.at> wrote:> On Wednesday, 2009-07-22, Tom Albers wrote: >> Op Wednesday 22 July 2009 23:32 schreef u: >> > > 2) Split akonadiconsole into its own package >> > >> > Maybe we could ask upstream to move it to back kdepim(libs)? Debugging >> > tools do not really belong to -runtime packages, do they? In my opinion, >> > if to split off akonadiconsole, then invent another package name like >> > kdepim-runtime-dev- tools (similar to qt4-dev-tools) or something. >> >> We can not move it to kdepimlibs as it depends on kdepim-runtime. Depending >> on -runtime at build time, kind of defeats the purpose ;-). > > At least not for now. > AFAIK the plan is to move it out to kdepim once the dependency issues are > resolved, e.g. libraries currently in kdepim-runtime become public API and > move to kdepimlibs. > > I would recommend to leave it in kdepim-runtime for now, also because it is a > really helpful for diagnosing Akonadi setup related problems. > Akonadi is currently mainly interesting for users which want to try new > technologies, e.g. for testing purposes, and at this point they can give more > valuable feedback when having access to akonadiconsole.Ok, at Kubuntu we are moving it from the Development to the System category for the time being. Even though it is most useful for diagnosing purposes, it does not have to be in-your-face visible to _our_ users :) If we should decide to split it into a separate package later on, I suppose we should indeed go with the -dev-tools approach. Thanks for the input everyone :) regards, Harald