El Dilluns, 23 de setembre de 2013, a les 08:45:29, Kevin Ottens va escriure:
> On Saturday 21 September 2013 15:25:27 Albert Astals Cid wrote:
> > 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.
>
> Well, I'm not sure we want to do that. This docbook seems useful only
> because kconfig_compiler --help does a poor job at documenting itself. So
> what about completing kconfig_compiler --help output to make it useful and
> get rid of the docbook?
So we don't have a man page anymore? Debian will be happy :D
Also we're losing the i18n-zation side of the man page, which the current --
help does not have.
But anyway we seem to be cutting features here and there in sake of
tierization, i guess this one is a minor one.
Since I'm not doing any meaningful frameworks work, O guess it's up to you
guys if we want to have the features we had or settling for less is good
enough.
Cheers,
Albert
>
> To me it looks like most of the docbook files in kdelibs are pretty much in
> the same situation and I'd favor proper --help support there than adding a
> dependency on kdoctool.
>
> Regards.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
