Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Aug 2007 21:19:13 +0300:
>> (OTOH, now that portage is recompressing >> all such files based on the PORTAGE_COMPRESS setting, I suppose it's >> possible the user screwed up their PORTAGE_COMPRESS setting. Still, if >> they screw up portage variables they should /expect/ it to have >> problems.) >> >> > No. PORTAGE_COMPRESS doesn't affect what's inside upstream tarballs :) > Read /usr/lib/portage/bin/dodoc and you will see that it's actually > dodoc that calls ecompress :) Thus the point, tho I changed thoughts in mid-stream and wasn't entirely clear about it so it's understandable that you missed it. I had asked in which cases the file might be missing, true, and this doesn't fit there, correct. However, then I got thinking how else dodoc might fail. If you have a dodoc || die, and dodoc calls ecompress and that fails, then dodoc will fail as well, right? So if the user has screwed up PORTAGE_COMPRESS, that will ultimately cause the dodoc to fail, where it wouldn't have for the maintainer who had a working ecompress. I was simply saying that's one way it could fail, that the maintainer would have no control over, but that even then, it's nothing we can really worry about since on Gentoo, we ultimately leave a user to their own folly if they screw up make.conf. There's a point beyond which we simply assume they are grown up enough to handle their own misconfigurations. Donnie does have a valid point, however. There are potential corner cases with unusual USE flags. I'd still like to see a hard example, however, as /intuitively/, it's difficult for me to envision a case where that would apply to what is after all /documentation/. The case for dodoc (as opposed to say, dobin or dolib) would seem to me to be fairly straigntforward, either it's used or not, and it's hard to envision where obscure USE flags would affect it to the point of making testing impractical. I wouldn't call the "doc" USE flag "obscure" enough to qualify, but conceivably there's a package out there where dodoc is indeed called in obscure enough circumstances that testing would be difficult. (This is keeping in mind that -rX bumps wouldn't normally need to test the dodoc anyway, since it'll be using the same tarball as the original ebuild and dodoc shouldn't normally have changed. Thus, testing the dodoc conditions should normally be necessary only on tarball containing the target doc change.) -- 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 -- [EMAIL PROTECTED] mailing list
