> While I agree that at a technical level this is probably fine, it seems > like it's setting us up for support problems. Users and technicians > alike will look at things like file sizes, file checksums, and file mod > times, and will ask questions about why their two installations don't > match. There's an answer that might well satisfy them, but the mere > fact that they asked the question costs us time and customer confidence.
I'll take you back to Danek's original answer: pkg verify. We have an existing mechanism, built into the pkg client, that verifies checksums, permissions, etc. I don't know what argument you're trying to make. Do you really believe users and technicians are incapable of learning a new set of tools? > If we believe that there are parts of ELF files that (a) routinely > change and (b) don't matter, and we want to avoid delivering unnecessary > change to the customer, perhaps we should do that filtering at an > earlier point, so that we never even deliver the change internally... > perhaps all the way back to not including those sections in the file in > the first place. Omitting sections that change contradicts your argument in favor of supportability. CTF, a very useful debugging tool for us, has non-deterministic output. We'd like that information to be in the binary, but it changes from build to build, even if the binary doesn't. That's just one example. We don't add random sections to binaries and ship them to customers because we feel like it. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
