Ciaran McCreesh wrote: > And why does repoman do that? > > Oh. Yeah. Because people with an attitude like yours think that the > correct way to fix a repoman message is to start nuking arch keywords, > ignoring what it does to the rest of the tree.
Dropping keywords works perfectly to have repoman quit complaining, you just have to do a recursive dropping on the rdeps of this package. > Perhaps because the people maintaining those archs have better things > to do that deal with the same silly ill-thought-out arguments every > three months. cia/cvs commits ml says something different, gentoo wise at least. >> I mean, if vapier can maintain arm/sh/s390, by himself, to a better >> degree than the mips *TEAM* can do, that should be an indication of a >> problem. > > That's an interesting assertion. Can you back it up? Feel free to run imlate scripts and come up with some numbers. Note that I hate whining and I love get solutions. MOST of the packages runs fine if they build fine, MOST of the endian-issues or the 64bit-issues got caught by ppc and amd64 and there aren't that many right now. Ugly arch specific codepath could be present, but, as I said, usually you catch those breaking on gcc. So having some way to test if the package builds (cross toolchain) and if the package at least runs (qemu) IS something that should let small arches with large tree coverage improve a bit. Otherwise you can just reduce the tree coverage. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
