Re: info-dir translator

[Alfred M\. Szmidt]

   > Running `install-info' as part of `make install' might have made
   > sense when package managers were infrequent, but now it doesn't.

   Well, we disagree here.  I would rather see more of the work done
   by package managers get pushed upstream, so there would be less
   duplication of effort for redistributors/repackagers, and less
   incompatibility among the repackaged versions of the same upstream
   package.

I think we partially agree, I too would like to see most (or at least
more) of the functionality moved upstream.  Infact, I'd like to see a
automake target called 'make package' or some such that would produce
a binary package that can be used on GNU (and systems that support
such packages).

But, the Info `dir' file causes problems with a system where you have
one directory per package, i.e. something that could be used by GNU
stow (it will cause conflicts, since many packages will contain a
`dir' file).

   > Well, the main system that GNU programs should run on is GNU, if
   > we don't use the facilities that GNU provides, what is the point
   > of having a GNU system?

   Non-GNU programs will also run on the GNU system.

If those non-GNU packages use the GNU build system, then all would be
well I think.  If not, then they probobly need porting anyway.

   > Of course, we shouldn't introduce incompatibilities just cause
   > one can...  But when they make the overall system nicer to work
   > with, I don't see why we shouldn't introduce them.

   The key point is how much is considered to be part of "the overall
   system".  If you only include GNU software running on the GNU
   system, then you'll end up causing problems for people who try to
   write portable software, whether it's under the GNU aegis or not.

Indeed, GNU programs are "notorious" for being portable across
operating system, even non-GNU ones.  Compared to the BSDs where
programs can use/abuse any feature that is available on that specific
implementation.

I think this is better answered by RMS than by me.  What comes first
for a GNU project?  Portability across (free) operating systems, or
adding features that might make programs less portable, but makes use
of GNU (or Hurd) specific features?

   But if you also consider those other effects, then I think you'll
   find that you can avoid creating portability problems without
   seriously impacting GNU.

Agreed, as I said, introducing incompatibilities without a good reason
is just a no-no.

Happy hacking!