1 |
On Monday 26 December 2005 10:26, Diego 'Flameeyes' Pettenò wrote: |
2 |
> I wouldn't like this. |
3 |
> The reason is, they are also used in eclasses that might be generic; while |
4 |
> for example kde eclass checks for the presence of files before dodoc-ing |
5 |
> them, I would rather see it ignore the actually presence or less of the |
6 |
> files, and just dodoc the one that exists, without failing if some does not |
7 |
> exists. |
8 |
|
9 |
I'm not sure if we're on the same page as far as the target audience of this |
10 |
change. The target audience is developers/those with strict in their |
11 |
features. The whole reason it's done is to be a bit more "strict" (hence the |
12 |
FEATURE phrasing) on general QA. For users that don't need this level of |
13 |
strict checking, they simply disable the feature. Generalized assumptions of |
14 |
code finding files simply isn't clean. Checks should be done to verify files |
15 |
before attempting to install, that's just the way it should be out of general |
16 |
practice. |
17 |
|
18 |
> One can be reasonably safe that it will find AUTHORS ChangeLog README NEWS |
19 |
> and TODO files in generic packages, if they follow GNUs style for example, |
20 |
> but sometimes they can be missing. |
21 |
|
22 |
Yes, but while GNU style is indeed the more popular of build sytems, others |
23 |
still do exist, and will continue to exist. I've always found dodoc should |
24 |
be checked anyways, and if we're assuming the documentation consists of the |
25 |
formentioned items, then we're also having the situation of missing other |
26 |
important documentation as well. This all should be checked the first time a |
27 |
package is imported/version bumped for consistancy. |
28 |
|
29 |
> I'd rather not see the change. |
30 |
|
31 |
Chris White |