| 1 |
Robert Buchholz wrote: |
| 2 |
> A problem package would be one that does not need a C compiler. It can't |
| 3 |
> be distinguished from the one which was not yet changed to depend on C. |
| 4 |
> |
| 5 |
> The problem here is that one can not say when the whole tree is updated |
| 6 |
> to the new standard, because for the packages which were not touched, it |
| 7 |
> could mean that they needed no change or that they were not looked at yet. |
| 8 |
> |
| 9 |
I can understand that as a maintenance issue. My query is whether having two |
| 10 |
different types of pkg would effect users in any way. |
| 11 |
|
| 12 |
> A solution to distinguish the two categories is to mark the packages |
| 13 |
> which were "checked", so you know: |
| 14 |
> 1. If it's checked and doesn't depend on cc -> category 1 |
| 15 |
> 2. If it's not checked and doesn't depend on cc -> category 2 |
| 16 |
> |
| 17 |
> Then, when all packages are checked, the tree is upgraded. |
| 18 |
> |
| 19 |
Sure, that makes sense. It sounds a heckuva lot like a database ;) |
| 20 |
|
| 21 |
Minor point- how can you tell in cat 2 that it definitely does not need a C |
| 22 |
compiler if it hasn't been checked? I'm guessing you were tired :) In any |
| 23 |
event in terms of maintenance, we'd need a tri-state: unchecked, checked |
| 24 |
and needs compiling, checked and doesn't (eg scripts). |
| 25 |
|
| 26 |
In terms of maintaining the metadata, am I right in thinking it's all just |
| 27 |
kept within the text files in the tree? |
| 28 |
|
| 29 |
-- |
| 30 |
gentoo-dev@g.o mailing list |
Archives