Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages

[Robert Buchholz <rbu@gentoo.org>]

Steve Long wrote:
> Robert Buchholz wrote:
>> The problem here is that one can not say when the whole tree is updated
>> to the new standard, because for the packages which were not touched, it
>> could mean that they needed no change or that they were not looked at yet.
> I can understand that as a maintenance issue. My query is whether having two
> different types of pkg would effect users in any way.

You're right, it would not be a problem for usability.


>> A solution to distinguish the two categories is to mark the packages
>> which were "checked", so you know:
>> 1. If it's checked and doesn't depend on cc -> category 1
>> 2. If it's not checked and doesn't depend on cc -> category 2
>>
>> Then, when all packages are checked, the tree is upgraded.
>>
> Sure, that makes sense. It sounds a heckuva lot like a database ;)
> 
> Minor point- how can you tell in cat 2 that it definitely does not need a C
> compiler if it hasn't been checked? I'm guessing you were tired :) In any
> event in terms of maintenance, we'd need a tri-state: unchecked, checked
> and needs compiling, checked and doesn't (eg scripts).

No, no. I did not mean that "category 2" does not need a C compiler. I
referred to Alec's mail which had "2. Packages that don't yet depend
upon C-compiler".
As for the state problem, when saving "checked" and "unchecked" as a
package's metadata, you will get the other properties (needs cc, needs
<insert system dep>) out of its DEPEND.


> In terms of maintaining the metadata, am I right in thinking it's all just
> kept within the text files in the tree?

Since the tree itself is the best database of the packages available,
anything else would be a lot more overhead.

But I had the impression the idea was discarded anyway. So I should
focus my thoughts somewhere else :-)


Ciao,

Robert

-- 
gentoo-dev@gentoo.org mailing list