On 26/08/2005, at 1:31 PM, Grobian wrote:
> Mike Z. wrote:
>> Definitely, compilation is fine, but you need to have some sort of
>> runtime testing as well. On the note of libraries, I would think,
>> rather than keywording libraries that compile, we should wait
>> until an application that requires them also needs to be
>> keyworded. This will probably depend on which library it is, but
>> it'd mean that we have a full deptree for each application, as
>> well as a useful real-world test case.
> This is in general the case. We cannot keyword a library without
> having it tested. My keyword for mp (the editor) was an example of
> this, I needed something small to test libpcre. I think when
> people report a library working/compiling, they use the library in
> some application. Maybe that application is not in portage, or so
> big that it isn't an appropriate test case,
It's a good point, that's why I mentioned that libraries would need
to be assessed on a case-by-case basis, (although applications
outside of portage are outside our scope).
> but I'd still like to keyword (unstable) libraries before a
> separate bug for an application using the library is there, because
> it's enormously annoying to have to keyword a whole tree of
> dependencies to figure out the 6th level dependency does not and
> will never compile.
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?
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.
I'm only suggesting that it makes more sense to test/keyword
libraries with applications, rather than on their own.
Mike Z. [shootingstar]
email@example.com mailing list