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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
