Making KDocTools independent of KArchive

Albert Astals Cid aacid at kde.org
Sat Sep 21 13:25:27 UTC 2013


El Dissabte, 21 de setembre de 2013, a les 11:15:52, Stephen Kelly va 
escriure:
> Albert Astals Cid wrote:
> >> No. I'm saying it can store and load .bin files which are processed with
> >> q{Unc,C}ompress.
> >> 
> >> There does not seem to be any need or reason for them to be .bz2.
> > 
> > There is no need for it to be a .bz2 other than "it is what it does and if
> > you change it you are going to break stuff that uses it". So yes, no
> > reason.
> 
> What would break? Everything that reads and writes those files is in-tree.

Right, i tought khelpcenter did some of the decoding, but it's done via 
meinproc too.

> 
> >> > Anyway as I was chatting with Aleix yesterday, kdoctools being a tier1
> >> > framework "is not enough" since kconfig has docbook files (e.g. man
> >> > page of kconfig_compiler) so we need a tier0 here ;-)
> >> 
> >> Where is kconfig now?
> > 
> > Do I really need to do an ls for you?
> 
> What I was trying to get at is that you seem to be implying that kconfig
> depends on kdoctools (ie, a tier1 depends on a tier2), therefore kdoctools
> can't be tier1. I don't follow that logic.

Well, kconfig depends on kdoctools because as I said there is a docbook for 
the kconfig_compiler manpage.

So yes, there is a tier1 that depends on a tier2. That if as I understand we 
plan to ship the kconfig_compiler manpage together with the kconfig framework 
tarball.

Cheers,
  Albert

> 
> Thanks,
> 
> Steve.
> 
> 
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel



More information about the Kde-frameworks-devel mailing list