> 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! _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
