| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Monday 03 May 2004 06:48, John Nilsson wrote: |
| 5 |
> > All package documentation is accessible from http://localhost/doc/ |
| 6 |
> > in the default apache configuration files. |
| 7 |
> |
| 8 |
> What about /usr/share/doc/, /usr/share/man/ and /usr/share/info/? |
| 9 |
> |
| 10 |
> app-text/man2html and app-text/info2html seems to be the right tools. |
| 11 |
> |
| 12 |
> /usr/share/doc/ would need ebuild support to be converted to html |
| 13 |
> though. |
| 14 |
> my system has 361 dirs in /usr/share/doc/ of which 68 has a html/ |
| 15 |
> subdir. |
| 16 |
|
| 17 |
/usr/share/doc is available. It is not available as html, but normally |
| 18 |
the compression is handled transparently by the browser. Man and info |
| 19 |
are more complicated and some cgi scripts are needed for it. |
| 20 |
|
| 21 |
> > The biggest problem is that the ebuilds can only be parsed using |
| 22 |
> > bash. If that restriction can be lifted (by restricting / changing |
| 23 |
> > the ebuild format) parsing should go a lot faster. Really the |
| 24 |
> > installed package database is not the problem. |
| 25 |
> |
| 26 |
> It seems that a lot of the information in ebuilds could be stated |
| 27 |
> declarative rather than imperative as it is now. Changing the ebuild |
| 28 |
> format to xml could be beneficial. The imperative sections could |
| 29 |
> remain and then fed to bash as the result of an xslt transformation. I |
| 30 |
> see no reason why portage couldn't support two formats in a transition |
| 31 |
> period. |
| 32 |
|
| 33 |
That is right, we will have a declarative ebuild format for portage-ng, |
| 34 |
but there are too many ebuilds currently using imperative features. |
| 35 |
|
| 36 |
> A small performance/space improvement would be to keep one file per |
| 37 |
> package rather then by version. |
| 38 |
|
| 39 |
This is not really an option. |
| 40 |
|
| 41 |
> |
| 42 |
> > I see what you mean. There are two problems. It is very hard to make |
| 43 |
> > a progress bar as using useflags means that we cannot give a good |
| 44 |
> > idea of the amount of code to be compiled in total. Even measuring |
| 45 |
> > what has allready been done is hard. Also removing the build output |
| 46 |
> > creates much problems for bug-hunting. |
| 47 |
> |
| 48 |
> This is not a portage issue. Make could be patched to calculate the |
| 49 |
> amount of code (in kb) that would be considered for a particular |
| 50 |
> target. I have no idea what kind of overhead we are talking about here |
| 51 |
> though. |
| 52 |
|
| 53 |
If you would create the patch I think that it would be useful for some |
| 54 |
people. Know though that many make files (almost all automake files) are |
| 55 |
broken and will not lead to a proper dependency tree (also causing "make |
| 56 |
- -j" problems) and as might not be easy to put into a progress counter. |
| 57 |
|
| 58 |
Paul |
| 59 |
|
| 60 |
- -- |
| 61 |
Paul de Vrieze |
| 62 |
Gentoo Developer |
| 63 |
Mail: pauldv@g.o |
| 64 |
Homepage: http://www.devrieze.net |
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 67 |
|
| 68 |
iD8DBQFAlfsibKx5DBjWFdsRAtTnAJ9g7ib8qGiqyRYqMz80rSlcQA/oRQCeLaMt |
| 69 |
hj9gdUNBf6ey4gpD6orhrWE= |
| 70 |
=rTMg |
| 71 |
-----END PGP SIGNATURE----- |
| 72 |
|
| 73 |
-- |
| 74 |
gentoo-dev@g.o mailing list |
Archives