KJournald in KDE-Review

Aleix Pol aleixpol at kde.org
Wed Oct 12 02:56:03 BST 2022

On Tue, Oct 11, 2022 at 9:47 PM Andreas Cord-Landwehr
<cordlandwehr at kde.org> wrote:
> On Montag, 10. Oktober 2022 15:34:30 CEST Aleix Pol wrote:
> > On Sun, Oct 9, 2022 at 7:18 PM Andreas Cord-Landwehr
>  [...]
> > > Even though KJournald is currently contained in the "libraries" playground
> > > module, I would like to get it included in the "utilities" module after
> > > passing KDE Review. The reason is that at the moment I more focus on the
> > > application part and that is the most user-facing part. Having it in
> > > "utilities" thus will avoid confusion.
> > >
> > > Looking forward for your review comments!
> >
> > I'm a bit confused by the context.
> >
> > It's placed in libraries although it seems like system would be the
> > place for it.
> > https://invent.kde.org/system
> >
> > I see there's a library, are you planning on maintaining compatibility
> > there? Are there other users? If there's no users outside, it could
> > make sense to skip installing headers until there is a use-case,
> > otherwise you might see yourself tied to an ABI unnecessarily.
> Yes, the https://invent.kde.org/system module sounds actually to be the best
> place for the app; I wrote "utilities" in the original mail, but agree that
> system is even better.
> I myself have use cases to use the library part as a library. Yet that is not
> for a public project. I could introduce a build option to only install headers
> optionally (default being OFF), which might makes it more clear to packagers
> that currently they do not have to package the headers. Moreover, at the
> moment their is not yet a fully stable API for the library, which is probably
> another good reason to not install headers by default.
> In the mid-term/long-run, I am planning to provide a stable API for the
> library.

Then I'd recommend to only make it public API when the time comes. :)

+1 to making it optional instead, if it makes your life any better.
That said, when we've needed this kind of flexibility in the past, we
have often ended up splitting the repository into a separate one, not
sure it would make sense here.

Also it would be useful to know what your plans are. :D


More information about the kde-core-devel mailing list