1 |
Though it makes sense to be able to specify a prefered document format in the |
2 |
USE variables, a blanket 'docs' variable doesn't make a lot of sense to me -- |
3 |
at least not in the case of most of the documents I'm thinking of. |
4 |
|
5 |
Going back to my previous example, it makes sense that Python documents be |
6 |
separate from the the Python interpreter. Why? Because everyone needs the |
7 |
interpreter (to run Portage), but only developers are going to use the |
8 |
tutorials and references. |
9 |
|
10 |
On the other hand, just because I want the docs for Python, it doesn't mean |
11 |
that I also want the docs for Ruby, or the Linux HOWTO docs. Using a USE var |
12 |
would mean that I had to set it depending on what package I was installing. |
13 |
|
14 |
To me, it makes sense to come up with a convention for splitting documents |
15 |
from applications, and making the docs easy to find. |
16 |
|
17 |
Matt |
18 |
|
19 |
On Tuesday 08 January 2002 07:33 pm, you wrote: |
20 |
> On Tue, 2002-01-08 at 19:09, Aron Griffis wrote: |
21 |
> > tvon@×××××.org wrote: [Tue Jan 08 2002, 06:41:58PM EST] |
22 |
> > |
23 |
> > > Speaking of which (which being docs for packages), is there any |
24 |
> > > validity to having a USE for 'docs' which determines weather or not |
25 |
> > > varios package docs are built along with the package they go with? |
26 |
> > |
27 |
> > This sounds like a really good idea to me. |
28 |
> |
29 |
> Hi! |
30 |
> |
31 |
> I have been thinking about this also. My thoughts. |
32 |
> |
33 |
> Possible USE variables: dochtml, docpdf, docinfo |
34 |
> Most Gnu packages have all the documetation in the package tarball and |
35 |
> allow you to build to a variety of formats. I personally prefer html |
36 |
> for reading locally in a browser. Other people may want info for in |
37 |
> console and emacs and others pdf for printing. Building pdf |
38 |
> documentation from source would require a PAPER environmental variable |
39 |
> to set the users preference, i.e. letter, A4, etc. Most (but not all) |
40 |
> Linux Documentation Project stuff is available in sgml so it can be |
41 |
> built to preference also. I have played around with this for some gnu |
42 |
> packages and python. (Unfortunately, I have never been able to build |
43 |
> the python documentation from the source tarball) |
44 |
> |
45 |
> Advantages: |
46 |
> |
47 |
> 1. fewer megabytes downloaded (especially nice for those on dial-up) |
48 |
> 2. fewer megabytes archived on ibiblio |
49 |
> 3. fewer doc ebuilds required in app-doc |
50 |
> 4. user flexibility |
51 |
> |
52 |
> Disadvantages: |
53 |
> |
54 |
> 1. added size and complication of ebuilds. |
55 |
> 2. not all packages include extensive documentation (manuals, tutorials, |
56 |
> etc) in the source tarball or if they do, include prebuilt html and/or |
57 |
> pdf but not necessarily both. How to handle case where docpdf is set, |
58 |
> but only html is available. |
59 |
> 3. program may build ok, but buggy documentation build could cause the |
60 |
> merge to fail. |
61 |
> |
62 |
> tod |
63 |
> |
64 |
> |
65 |
> |
66 |
> |
67 |
> _______________________________________________ |
68 |
> gentoo-dev mailing list |
69 |
> gentoo-dev@g.o |
70 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev |