[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: 2004.2 Feature Requests
From:       Paul de Vrieze <pauldv () gentoo ! org>
Date:       2004-05-03 7:56:08
Message-ID: 200405030956.18301.pauldv () gentoo ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 03 May 2004 06:48, John Nilsson wrote:
> > All package documentation is accessible from http://localhost/doc/
> > in the default apache configuration files.
>
> What about /usr/share/doc/, /usr/share/man/ and /usr/share/info/?
>
> app-text/man2html and app-text/info2html seems to be the right tools.
>
> /usr/share/doc/ would need ebuild support to be converted to html
> though.
> my system has 361 dirs in /usr/share/doc/ of which 68 has a html/
> subdir.

/usr/share/doc is available. It is not available as html, but normally 
the compression is handled transparently by the browser. Man and info 
are more complicated and some cgi scripts are needed for it.

> > The biggest problem is that the ebuilds can only be parsed using
> > bash. If that restriction can be lifted (by restricting / changing
> > the ebuild format) parsing should go a lot faster. Really the
> > installed package database is not the problem.
>
> It seems that a lot of the information in ebuilds could be stated
> declarative rather than imperative as it is now. Changing the ebuild
> format to xml could be beneficial. The imperative sections could
> remain and then fed to bash as the result of an xslt transformation. I
> see no reason why portage couldn't support two formats in a transition
> period.

That is right, we will have a declarative ebuild format for portage-ng, 
but there are too many ebuilds currently using imperative features.

> A small performance/space improvement would be to keep one file per
> package rather then by version.

This is not really an option.

>
> > I see what you mean. There are two problems. It is very hard to make
> > a progress bar as using useflags means that we cannot give a good
> > idea of the amount of code to be compiled in total. Even measuring
> > what has allready been done is hard. Also removing the build output
> > creates much problems for bug-hunting.
>
> This is not a portage issue. Make could be patched to calculate the
> amount of code (in kb) that would be considered for a particular
> target. I have no idea what kind of overhead we are talking about here
> though.

If you would create the patch I think that it would be useful for some 
people. Know though that many make files (almost all automake files) are 
broken and will not lead to a proper dependency tree (also causing "make 
- -j" problems) and as might not be easy to put into a progress counter.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAlfsibKx5DBjWFdsRAtTnAJ9g7ib8qGiqyRYqMz80rSlcQA/oRQCeLaMt
hj9gdUNBf6ey4gpD6orhrWE=
=rTMg
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread]