2006/9/3, Jason Chu <[EMAIL PROTECTED]>: > On Sat, 2 Sep 2006 18:17:01 +0200 > How would your file be different from anyone else's? A developer's > perhaps?
It wouldn't. But I have 533 packages in my cache, and it took almost three hours to check them all. It would not be the first time that the devs benefit from something like this without having to download all the packages and do all the computational work by themselves... > You know you could just run namcap /var/cache/pacman/pkg/* > > ~/badpackages.log... Uh, didn't know. I got used to pacman's syntax, which not always does accept multiple names... thanks ;-) > As long as developers are doing their jobs, they should have run namcap > on the package before pushing it to the server. Shouldn't that > information be the same? Yeah, they should've done it, but it doesn't seem everyone has done so. I've got a really huge file (10958 lines, 3685 if we remove the ones related to non-standard directories [still 34 packages] and to testing packages), and some entries just shouldn't be ignored. A few stats: -138 included but already satisfied dependencies -497 included and not needed deps (many false positives here for unrecognized deps, mostly for interpreted languages) -471 libtool occurrencies... and I doubt they're all necessary -186 deps detected and not included (false positives here sometimes) Do I need to go on? I'm not blaming the developers, I think it is something that happens normally with time. It just needs to be fixed, and the devs are the ones who can do it. If the help of the community is needed, then we could call a dep-fixing day, rather then a bug-squashing one... > I've always wanted to keep namcap a simple rule-based package checker. > I wouldn't want to sully its simplicity with an exception db. Also, > who would maintain it? How often would it be updated? Who says what > messages are non-needed? Yeah, that was just an idea. I don't really like it, too, but discussion is good, maybe we'll come up with some good ideas. You're right, it'd be really difficult to maintain, but I don't see any point in advising the dev that /home/httpd is not a standard dir: he knows it, he's the one who did it, and he did on purpose. This is surely not enough, but there's more: it *is* standard for apache under arch, isn't it? So why bother? Another idea I don't like but may inspire someone to find something with more sense: every package could have a namcap-targeted file that says: yeah, I know you think I need gcc, but believe me, I don't, and I know that those files seem to be where they shouldn't, but leave them alone. The problem of this approach is the lack of extensibility of arch's package format, which is somewhat strict with the metadata, I think to understand... Anyway, thanks for your answer =) bardo _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
