On Fri, August 26, 2005 08:04, Mike Z. wrote:
> That wasn't exactly my point, my point was that we should hold off
> keywording libraries until they will actually be used by an
> application that is keyworded, and hence properly tested.
> With libraries it's important to consider what will actually be
> compiled against them (the reverse deptree) - ie, the library might
> compile, but how do we know applications will compile/run against it?
eh, yes, currently we require at least one application to compile/run
against the library (we call it 'testing' I think)
> Well in that case, we have to test them... and if we've tested them
> (assuming they pass, or are modified to pass), then we can keyword them.
which is what we do
> I'm only suggesting that it makes more sense to test/keyword
> libraries with applications, rather than on their own.
We (at least I) don't keyword a library that has no application which uses
the library, to be sure there is at least one program that was happy when
using the library. It's impossible to do an exhaustive test of all
applications using the library. That's where my testing proposal was for.
I get your concerns, but I don't think they are valid, as I think we deal
with libraries as you propose. That's why keywording libraries suck, you
need to do at least two things: 1) getting the library to compile/install
and 2) finding/testing with an application that uses the library (which
may not be that obvious like pcre).
I think that whenever we keyword a library, it usually is part of a larger
tree of packages depending upon each other. Since the dependencies should
be keyworded before the depending package (portage policy), and we don't
want the dependency around before the package that depends on it
(testing), we end up in an 'atomic' commit where both library and
application are keyworded at once.
email@example.com mailing list