On Sun, 3 Sep 2006 02:04:08 +0200 bardo <[EMAIL PROTECTED]> wrote: > 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 think specific problems reported to the bug tracker would help the developers. A wholesale scanning of all packages won't really help cause none of the developers will want to sift through it and figure out what problems are problems and what aren't... > > 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... It's true, we don't have any room for metadata like that right now. Though, it could be added. My fear is that they would be abused and the assumptions wouldn't be checked ie. if a package *did* depend on gcc that next version, but the developer told it to ignore that message, how would they even know to check? > Anyway, thanks for your answer =) Jason -- Two years ago, I generated a gpg key that expired August 24, 2006 (686FD13C). I've now generated a new one (C7EFE9F4).
signature.asc
Description: PGP signature
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
