Re: make distcheck fails for simple Makefile.am

[Roger Leigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bob Friesenhahn <address@hidden> writes:

> On Sat, 2 Jul 2005, Roger Leigh wrote:
>>
>> Thanks.  I read this, but I still don't think this is the correct
>> solution.  I can see this would work well for a user-extensible
>> program, such as the GIMP, which has system and user plugin and module
>> directories.
>>
>> For system-level programs, there is only one install location.  In the
>> case of CUPS, the directories for data, backend binaries and filter
>> binaries are fixed.  Being able to specify an alternate location with
>
> In this case CUPS must be broken software.  Fixed at install time is
> considerably different than "hard coded" in the source code.

I was probably not clear.  CUPS has a configure script, with which I
can specify --prefix and whatever other configure options I like.  For
any given CUPS installation, there will therefore be a defined set of
directories in which to install backend drivers, filter drivers and
driver data.  Because its a "service", running as root/lpadmin, it is
not user-extensible.  The search path for extensions is fixed to a set
of directories within its configured prefix, one per extension type
(e.g. $prefix/share/cups/model and $exec_prefix/lib/cups/filter).

My package is a CUPS _driver_, i.e. an extension.  It asks CUPS (via
cups-config) what those configure options were.  It makes no sense for
this to be a configure option in _my_ script: if it doesn't use the
ones from CUPS, CUPS will not see my driver, because it installed in
the wrong place.  My package could be configured with a totally
different prefix, and it will happily install its shared libraries,
modules and data there, but the parts that bridge with CUPS must go
where CUPS wants them.

I hope I've made that clear.  There are two separate packages,
configured independently, but the second (mine) is dependent upon the
first to a certain extent.  My package is split into
- - "normal" programs, libs and data.  These live in the standard prefix
- - "interface" programs and data.  These go where configure detects
  they should go.  You can specify via the CUPS_CONFIG variable which
  CUPS installation it should use, but the installation settings are
  extracted from cups-config.
- - There are several "interface" parts, for other printing systems
  e.g. foomatic.  This also relies on previously-installed binaries
  (foomatic-kitload) in order to install.  This is again for the same
  reasons.
- - In effect, my package is actually configured with several different
  prefixes, e.g. $prefix and $cups_prefix.  The former is the the
  normal one, the latter from the cups-config script (though it's more
  complex than that--it picks out each separate directory rather than
  a general prefix).

>> In the case of programs using Linux-PAM (libpam), /etc/pam.d and
>> /etc/security are the only places you could install authentication
>> service configuration files.  It doesn't make sense to have any other
>> place for e.g. SSH configuration, and it would be a security issue to
>> boot.  Even if a user builds their own SSH, it will still need to look
>
> Sorry, my SSH configuration files are not under /etc.  There were good
> reasons to put them somewhere else (besides the fact that OpenSSH
> defaults to elsewhere).  I don't see how relocating these files could
> be a security issue.

You can configure ssh in several ways (it was just an example of a
PAM-using service); I simply described the way it's done on Debian
GNU/Linux.  Perhaps you don't use PAM?

The point was not about SSH, but about libpam.  This can't be altered,
and IMHO for good reasons, but we do need to be able to cope with it
whether or not we like it.

> Putting sensitive files in non-default locations actually improves
> security.  If /bin/sh could be moved, then system security would
> improve immensely, but unfortunately, it is inconvenient to move.

> There are very few programs on a Unix system that I would call
> "system-level programs".  Certainly the process with PID=0 and
> (possibly) 'init' fall into this category.  Everything else is just
> application software.  In fact, it should be possible to use an
> alternate program in the place of 'init'.  One person's "system-level
> program" is another person's relocatable/replaceable application.

This does not have any bearing on the actual problem with automake.

> It would be wrong to assume that the world is bound by Linux
> conventions.

The examples have nothing to do with "Linux".  These were just
examples of particular cases where I found automake breaking.  They
may be atypical, but they are real.  Whether we like it or not,
automake-using packages do have to co-exist and interoperate with
packages which might not do things as we would like.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCxwL5VcFcaSW/uEgRAs75AKCVYy3XHHbTv1ptndzUOB4zP2Q7PACgsXcn
ATTkicNA3IYHVi4ESGSjYTo=
=Yg8B
-----END PGP SIGNATURE-----