[gentoo-dev] Subcategores and a C comment

[Nicholas Jones]

> What's this I've heard about Portage's performance not being a
> real issue? (argument for not rewriting it in C/etc)

(Directed at individuals that persist in making such commentary:)

STOP SUGGESTING THAT until you know why it's rejected. Tree walking
will, at no reasonable level, be faster. DiskIO is a bound and there
is no direct way to make it faster in C, asm, or python. The only
realistic benefit of C would be algorithmic... and there is no problem
there except for searches. Any benefits beyond this incur a MASSIVE
testing and QA requirement because of the lower-level code involved.
You would not see nearly the changes and quickness in fixes if portage
were in C and I highly doubt anyone wants to diagnose segfaults on
a users box. Copy and pasting exceptions reduces debugging time by
leaps and bounds. 'Please run gdb on portage after recompiling your
system with frame pointers and debug information.' </rant>

Short version: C is my prefered language, what I code in at work,
and I think it's completely wrong for portage and wide deployment
of an actively changing system such as portage. It's more important
for portage to work than to be blazingly fast.

Any WELL THOUGHT argument or research should be taken to the
gentoo-portage-dev mailing list.

>> 2) how will Portage know the difference between a package
>> and another sub-category when it is walking the tree?

Categories file is easy enough to employ.

>> 3) the many additional directories would cause an 'emerge sync'
>> to take longer than it does now.

It would, but not as much as the thousands of ebuilds and
supporting files that get added to daily.

> should finally implement fetch-on-demand...

So instead of a sync connection and update, we can trade off a
complete tree for 1-to-N connections, comparisons, and fetches.

I'd recommend passing this through infra to make sure that
causing an extra N-times the connections is reasonable.

Also, you potentially cause the mirror to reject you as there
could be a great deal more competition on any given mirror.
Portage would be forced to add logic to repeatedly poll for a
free connection once it has started. If you get stuck behind
Dialup users, you could very well be there a while. Basically,
it can cause a race condition against servers.

>> Basically, you'd be pissing everyone off with little benefit
>> (except maybe to developer sanity).

It's not that bad really. But portage internals make a lot of
assumptions about the directory structure which is why we have
yet to make any attempt at this yet. It should become feasable
some time after 2.0.51 becomes stable and we branch for the
ripping apart of the internals.

--NJ