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.
eh, yes > 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 protected] mailing list
