Hi, On Fri, Mar 28, 2003 at 01:13:22PM -0000, Matt Ryan wrote: > > Count me interested. Count internet cafes and kiosk admins. > > > > I don't see why you are so against a change that won't affect you, but > > will enable others to do what they want. > > Because it will affect me in some way. The point is whether we want to > satisfy the (estimated) small number of users who *might* need this > functionality by making a large number of changes to packages (Russell has > provided an extensive list of those effected). This is very likely to > introduce bugs and make us non-standard WRT the other Linux distributions. OTOH: - actual distributions should never be standardised, only requirements should. Otherwise the standard will inevitably stand in the way of progress at some point without achieving anything productive. The standards are the FHS and LSB, not RedHat. The standard is SMTP, not sendmail. It's only painful that the DNS standard is so bind-centric. - The only purpose of standards is interoperability; among pieces of software, users or the administrator. A number of the files that would be affected by this change can only be used by a single package or program. In those cases there's little purpose to having a standard location for those files. - If we have the required FHS directories, and the required files are accessible in the ways that are required from their required locations, I really think we've fulfilled our obligations If a standard specifies that a file with a certain path name must be readable and writable and doesn't say that it may be unlinked and re-created at any point, then whether or not the file is a symlink is up to the implementation. - If something breaks because a standardized file is a symlink and the specification does not forbid a symlink, then that piece of software is not standards compliant, because it has stricter requirements than the specification. If we notice such brokenness, all the better, because we can then fix it and create more predictable behaviour. - /Any/ change is likely to introduce bugs. Even changes for the better. The good news is that you can fix bugs after you introduce them, while preserving the good bits. How's that? Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpOlQHUwNdKr.pgp
Description: PGP signature