Chen Lei wrote:
> How about qt-doc? Currently, it bundles src/qch/html docs, the src
> image files are completely useless and duplicate with files in html
> directory. The content of the qch and html docs is identical, since
> assistant_adp is dropped by qt 4.7, I suggest to split html docs into
>
2010/8/9 Kevin Kofler :
> Toshio Kuratomi wrote:
>> Depending on the technologies and applications involved I could see
>> duplication being okay when one format is meant for people utilizing
>> less /usr/share/doc/foo/* vs running /usr/bin/documentationviewer or
>> /usr/bin/programmer-ide
>
> Tha
I wrote:
> As for the Internet connection: I've just downloaded root-doc in 4
> minutes, at 2.5 megaBYTES per second. And that's in Vienna, Austria. There
> are places with even faster Internet connections.
PS: That's my HOME connection. You don't want to know how fast I could
download that file
Toshio Kuratomi wrote:
> Depending on the technologies and applications involved I could see
> duplication being okay when one format is meant for people utilizing
> less /usr/share/doc/foo/* vs running /usr/bin/documentationviewer or
> /usr/bin/programmer-ide
That's the case for the KDE stuff: p
Jonathan Dieter wrote:
> I've taken a look at the root source rpm, and it looks like root-doc is
> generated by root itself *after* root has been completely built (rather
> than as part of root's build process).
>
> I've opened a bug, https://bugzilla.redhat.com/show_bug.cgi?id=621812
> suggesting
Jonathan Dieter wrote:
> While in the general case, I would agree with you, in this specific
> case, I think it's worth building on the client. 687MB is a very large
> download, over 90 minutes on a 1mbit/s link, and 45 minutes on a 2mbit/s
> link. Because of the large size and number of files, i
Jonathan Underwood wrote:
> As I said in the bug report, I don't think building docs client side
> is the right way to go at all. In the general case this would require
> end users to install extra tools to build the docs, and defeats the
> purpose of a package managed system such as Fedora.
+1
I
On Fri, 2010-08-06 at 10:04 +0100, Jonathan Underwood wrote:
> As I said in the bug report, I don't think building docs client side
> is the right way to go at all. In the general case this would require
> end users to install extra tools to build the docs, and defeats the
> purpose of a package ma
On 6 August 2010 09:53, Jonathan Dieter wrote:
[snip]
>> No, please not...
>> Generating that documentation will take ages, so each time, %post needs
>> at least 45 min - 1 hour to complete...
>> (One of my reasons for switching to Fedora from Gentoo, was exactly
>> that amount of updating time. ;
On Fri, 2010-08-06 at 10:46 +0200, Thomas Spura wrote:
> On Fri, 06 Aug 2010 11:03:46 +0300
> Jonathan Dieter wrote:
>
> > On Fri, 2010-08-06 at 06:27 +0100, Jonathan Underwood wrote:
> > > On 5 August 2010 21:49, Toshio Kuratomi wrote:
> > > > Yaah -- so if it's useful documentation, then I'd be
On Fri, 06 Aug 2010 11:03:46 +0300
Jonathan Dieter wrote:
> On Fri, 2010-08-06 at 06:27 +0100, Jonathan Underwood wrote:
> > On 5 August 2010 21:49, Toshio Kuratomi wrote:
> > > Yaah -- so if it's useful documentation, then I'd be against
> > > creating a rule that bans it. The next question wou
On Fri, 2010-08-06 at 06:27 +0100, Jonathan Underwood wrote:
> On 5 August 2010 21:49, Toshio Kuratomi wrote:
> > Yaah -- so if it's useful documentation, then I'd be against creating a rule
> > that bans it. The next question would be whether it's useful or not
> > Public vs private certainl
On 5 August 2010 21:49, Toshio Kuratomi wrote:
> Yaah -- so if it's useful documentation, then I'd be against creating a rule
> that bans it. The next question would be whether it's useful or not
> Public vs private certainly sounds like one thing to look at. However, some
> libraries might
On Fri, Aug 06, 2010 at 01:45:08AM +0200, Kevin Kofler wrote:
> Toshio Kuratomi wrote:
> > I don't think we could just say don't package documentation that's
> > ridiculously large but perhaps we could make some sort of guideline about
> > not duplicating formats on extra large docs. Is the case w
Toshio Kuratomi wrote:
> I don't think we could just say don't package documentation that's
> ridiculously large but perhaps we could make some sort of guideline about
> not duplicating formats on extra large docs. Is the case with root-docs
> (and/or kdelibs-apidocs) that we have docs in text + h
On Thu, Aug 05, 2010 at 03:19:46PM -0400, Orcan Ogetbil wrote:
> On Thu, Aug 5, 2010 at 3:11 PM, Jonathan Dieter wrote:
> > On Thu, 2010-08-05 at 14:24 -0400, Toshio Kuratomi wrote:
> >> I don't think we could just say don't package documentation that's
> >> ridiculously large but perhaps we could
On Thu, 2010-08-05 at 15:19 -0400, Orcan Ogetbil wrote:
> On Thu, Aug 5, 2010 at 3:11 PM, Jonathan Dieter wrote:
> > Please note that I'm not saying "don't package documentation that's
> > ridiculously large", but rather, "don't package automatically generated
> > documentation that's ridiculously
On Thu, Aug 5, 2010 at 3:11 PM, Jonathan Dieter wrote:
> On Thu, 2010-08-05 at 14:24 -0400, Toshio Kuratomi wrote:
>> I don't think we could just say don't package documentation that's
>> ridiculously large but perhaps we could make some sort of guideline about
>> not duplicating formats on extra l
On Thu, 2010-08-05 at 14:24 -0400, Toshio Kuratomi wrote:
> I don't think we could just say don't package documentation that's
> ridiculously large but perhaps we could make some sort of guideline about
> not duplicating formats on extra large docs. Is the case with root-docs
> (and/or kdelibs-api
On Thu, Aug 05, 2010 at 01:23:24PM -0400, seth vidal wrote:
> On Thu, 2010-08-05 at 19:56 +0300, Jonathan Dieter wrote:
> > So I'm syncing up our school's local mirror over our rather slow
> > internet connection and I notice that the root-doc subpackage (which is
> > part of the root package) has
On Thu, 2010-08-05 at 19:56 +0300, Jonathan Dieter wrote:
> So I'm syncing up our school's local mirror over our rather slow
> internet connection and I notice that the root-doc subpackage (which is
> part of the root package) has just hit the slightly obese size of 687MB
> [1]. For reference, the
So I'm syncing up our school's local mirror over our rather slow
internet connection and I notice that the root-doc subpackage (which is
part of the root package) has just hit the slightly obese size of 687MB
[1]. For reference, the root source rpm is 27MB [2].
Now, I don't know if we have a poli
22 matches
Mail list logo
