Hasan Khalil posted <[EMAIL PROTECTED]>, excerpted below, on
Mon, 07 Feb 2005 21:37:55 -0500:
> 3) the {~,}ppc-macos keyword hasn't _existed_ for 1102 days.
>
> Umm... Now 3 other things.
> i) Is there perhaps something wrong with the script? ii) Are other
> archs seeing similar issues? iii) Has this already been discussed before?
iii) Yes, it has been discussed before.
i) No, nothing wrong with the script (except an invalid assumption, below).
ii) Yes, other archs see the same issue.
The problem is with portage. There's no way to directly extract when a
particular keyword is added. Thus, one can tell when an ebuild was added,
and see the ~arch listed, but without a way to tell when the ~arch keyword
was added, the assumption must be that it was added when the ebuild was
added. That's reasonable if not always correct (due to ebuilds being
-* for alpha level development and testing) for ~x86 and ebuilds upgraded
after an arch was added and an original ebuild version was keyworded,
since ~arch keywords normally carry forward, but it's NOT accurate where
the ~arch keyword was added months or possibly years after the ebuild was
introduced, because the arch is newer than the ebuild or no previous
ebuilds of that package had been tested and marked ~arch yet.
IOW, the problem affects nearly all non-x86 archs to a large degree.
The idea for the script is good, but barring portage support for tracking
the introduction of specific keywords, or barring a script intelligent
enough to go digging thru changelogs and the like, successfully parsing
them to find the missing data, the top-10 is always (well, for some
serious period into the future, anyway) going to be entirely a bunch of
noise, no signal, since there will always be more than 10 ebuilds where
an ~arch keyword was added long after the ebuild itself debuted.
One solution I've suggested before, would be to special-case all instances
where more than X entries appear to have the same greater than Y
reasonable period. By tweaking X to something reasonable, say five,
certainly ten or lower, and Y to something reasonable, perhaps a year and
a half or just round it to 500 days, it should be possible to eliminate
this "noise" and actually get a top-ten output that's useful in some way,
shape, or form.
Another alternative would be to eliminate this test all together, since
the script/bot checks for other unusual and normally undesired occurrences
as well. Or.. test for this only for ~x86. While this would eliminate a
potentially valuable warning, as is, the data is simply noise, and
therefore isn't useful at all, so the script would be more useful than it
is presently.
However, when I made that suggestion, I got no reply. IIRC I even sent it
both to the list and to the feedback address listed (as I'm doing here).
I've thought about seeing if the script source is available, figuring it
out, and mailing a proposed patch, but it hasn't happened yet.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
--
[email protected] mailing list
