[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ifupdown writes to /etc... a bug?



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: pgpfTYt84gZ5y.pgp
Description: PGP signature


Reply to: