Ryan Hill wrote:
> Robert Buchholz wrote:
>> I don't want to sound negative and I like the idea a lot, but two things
>> are on my mind about this:
>>
>> It should also sync with changes in the tree, like package removals,
>> additions and package moves.
>
> For sure.
>
>> When you're talking ab
Ryan Hill wrote:
> I just use a local db to keep track of stuff like this, but haven't
> thought of a way to turn this into a service and i don't think it's
> really doable. I think you'd need an entry for every ebuild in portage,
> times the number of archs, times an unlimited number of arbitrary
Robert Buchholz wrote:
> I don't want to sound negative and I like the idea a lot, but two things
> are on my mind about this:
>
> It should also sync with changes in the tree, like package removals,
> additions and package moves.
For sure.
> When you're talking about it on ebuild base: When a
Ryan Hill wrote:
> Steve Long wrote:
>> Robert Buchholz wrote:
>>> Since the tree itself is the best database of the packages available,
>>> anything else would be a lot more overhead.
>
>> I really don't agree, altho I could well be missing something. Surely there
>> should be a maintenance/QA da
Steve Long wrote:
> Robert Buchholz wrote:
> I understand that it's hard to distinguish a pkg that hasn't been checked,
> but might need the C-compiler, from a pkg that doesn't need the compiler
> but just hasn't been checked. That's where I was going with the database
> stuff.
>> Since the tree
