Re: make distcheck fails for simple Makefile.am

[Bob Friesenhahn]

On Sat, 2 Jul 2005, Roger Leigh wrote:


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.


Great.  So if you driver is a program, you could presumably establish 
a cups program directory via


cupsdir = $(CUPS_DRIVER_DIR)
cups_PROGRAMS = mydriver

mydriver_SOURCES = source.c
mydriver_CPPFLAGS = $(CUPS_CPPFLAGS)
mydriver_LDFLAGS =  $(CUPS_LDFLAGS)
mydriver_LDADD   = -lcups

Where CUPS_DRIVER_DIR, CUPS_CPPFLAGS, and CUPS_LDFLAGS are 
substitutions from your configure script.  The configure script will 
execute any necessary utility in order to obtain CUPS build options 
and install directories.


In this case, CUPS_DRIVER_DIR does not need to be derived from 
$prefix, but it should at least observe $(DESTDIR).  Perhaps 
$(DESTDIR)$(CUPS_DRIVER_DIR) is safest.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: make distcheck fails for simple Makefile.am

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bob Friesenhahn <[EMAIL PROTECTED]> 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/Linuxhttp://www.debian.org/
GPG Pu

Re: make distcheck fails for simple Makefile.am

[Bob Friesenhahn]

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.



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.  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.


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


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: make distcheck fails for simple Makefile.am

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:

 "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes:
>
>  Roger> It's often the case that a package installs files in locations picked
>  Roger> up by configure.  e.g. in gimp-print the CUPS PPD files get installed
>  Roger> in `cups-config --datadir`, and the drivers in `cups-config
>  Roger> --serverbin`/filter.  'make distcheck' has never worked because of
>  Roger> this.
>
> The FAQ entry `Hard-Coded Install Paths' has some suggestions.

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
configure is pointless: the locations specified with the -config
script are the only useful locations on the system.  Any other
location will result in a non-functional program.

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
there, even if different --prefix options were used: the libpam
library has this hardcoded for security.

These are certainly rare cases, but it would be nice if automake could
cater for them.

I read distdir.am, and saw the comment:

## Make sure the package has proper DESTDIR support (we could not test this
## in the previous install/installcheck/uninstall test, because it's reasonable
## for installcheck to fail in a DESTDIR install).

I can see the rationale here, but it would be nice to be able to do it
all the same if requested (I haven't written any installcheck stuff,
so it can't fail).


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://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 

iD8DBQFCxmkNVcFcaSW/uEgRAl5vAKDl+fJI2ZasdI1+9S4hrlKzcMw4oQCdELcT
7lmmB1DgWR1CcwwYXwvJBqU=
=30L2
-END PGP SIGNATURE-

Re: make distcheck fails for simple Makefile.am

[Alexandre Duret-Lutz]

>>> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes:

 Roger> It's often the case that a package installs files in locations picked
 Roger> up by configure.  e.g. in gimp-print the CUPS PPD files get installed
 Roger> in `cups-config --datadir`, and the drivers in `cups-config
 Roger> --serverbin`/filter.  'make distcheck' has never worked because of
 Roger> this.

The FAQ entry `Hard-Coded Install Paths' has some suggestions.
-- 
Alexandre Duret-Lutz

Re: make distcheck fails for simple Makefile.am

[Ralf Wildenhues]

Hi Roger,

* Roger Leigh wrote on Mon, Jun 20, 2005 at 11:11:10AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> > * Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST:
> >> 
> >> pamdir = /etc/pam.d
> >> pam_DATA = schroot
> >> EXTRA_DIST = $(pam_DATA)
> >> 
> >> make distcheck fails:
> >
> > Make that 
> >   pamdir = $(prefix)/etc/pam.d
> >
> > but you really should be using sysconfdir:
> >   pamdir = $(sysconfdir)/pam.d

> In this case, it will always be /etc/pam.d.  This directory is the
> location of the Linux-PAM service configuration files.  For security,
> libpam won't look anywhere else.  The package has other files to
> install in $(sysconfdir), so using $(sysconfdir) would be wrong
> because it's likely I might want that to be some other value.

That strikes me as inconsistent (for general packages).  In any case, it
prevents multiple installations of the same package under different
prefixes.

> I /could/ do this, but I would likely need to override pamdir during
> 'make install' if it was wrong, which really defeats the point.  If it
> only works when $(sysconfdir)=/etc, it's broken the rest of the time.

Make configure set sysconfdir to /etc unless overridden?  (That won't
solve the distcheck problem alone.)

> > So no, this is not a bug in Automake.
> 
> IMO the ability to use literal absolute paths is unconventional, but
> sometimes required.  If "make distcheck" used $(DESTDIR) rather than
> relying on the fact that *all* install paths begin with $(prefix), it
> would be rather more reliable.

Well, distcheck is meant for general purpose checking.  One item is
that packages should be installable in parallel.  Another one is that
packages should be usable by the powerless user (i.e., one without root
rights).  Both of these don't fit your package.

> It's often the case that a package installs files in locations picked
> up by configure.  e.g. in gimp-print the CUPS PPD files get installed
> in `cups-config --datadir`, and the drivers in `cups-config
> - --serverbin`/filter.  'make distcheck' has never worked because of
> this.

Hmm, DISTCHECK_CONFIGURE_FLAGS could help around this if the package
allows overriding.

> In both of these cases, the location is dictated by packages already
> installed on the system.  That location is completely independent of
> $(prefix).

OK.

> In summary:
> - - any location that does not start with $(prefix) will break distcheck
> - - this could be fixed by using $(DESTDIR)

Nono.  DESTDIR serves a different purpose, don't try to abuse it,
please.  It'll work with simple setups/packages only.

I agree with you that this is a limitation.  But I am still not sure
that it should be solved within Automake.  Why not have
 pamdir=/etc/pam.d

and set this in configure.ac but have it overridable by the user.  Then,
use DISTCHECK_CONFIGURE_FLAGS to have `make distcheck' pass?  I agree it
sounds like a hack, but then again, you _are_ violating packaging rules,
and IMVHO it's acceptable if it's difficult to get around them.

Just my opinion, though, I'd love to see arguments against it.

Regards,
Ralf

Re: make distcheck fails for simple Makefile.am

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> * Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST:
>> 
>> In a simple Makefile.am:
>> 
>> pamdir = /etc/pam.d
>> pam_DATA = schroot
>> EXTRA_DIST = $(pam_DATA)
>> 
>> make distcheck fails:
>
> Make that 
>   pamdir = $(prefix)/etc/pam.d
>
> but you really should be using sysconfdir:
>   pamdir = $(sysconfdir)/pam.d
>
> so that both the casual user and the distribution packager can easily
> override the values: the former could do
>   configure --sysconfdir=/etc   # rest goes under /usr/local
> whereas the latter does
>   configure --prefix=/

In this case, it will always be /etc/pam.d.  This directory is the
location of the Linux-PAM service configuration files.  For security,
libpam won't look anywhere else.  The package has other files to
install in $(sysconfdir), so using $(sysconfdir) would be wrong
because it's likely I might want that to be some other value.

I /could/ do this, but I would likely need to override pamdir during
'make install' if it was wrong, which really defeats the point.  If it
only works when $(sysconfdir)=/etc, it's broken the rest of the time.

> So no, this is not a bug in Automake.

IMO the ability to use literal absolute paths is unconventional, but
sometimes required.  If "make distcheck" used $(DESTDIR) rather than
relying on the fact that *all* install paths begin with $(prefix), it
would be rather more reliable.

It's often the case that a package installs files in locations picked
up by configure.  e.g. in gimp-print the CUPS PPD files get installed
in `cups-config --datadir`, and the drivers in `cups-config
- --serverbin`/filter.  'make distcheck' has never worked because of
this.

In both of these cases, the location is dictated by packages already
installed on the system.  That location is completely independent of
$(prefix).

In summary:
- - any location that does not start with $(prefix) will break distcheck
- - this could be fixed by using $(DESTDIR)


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://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 

iD8DBQFCtogsVcFcaSW/uEgRAiKvAJ0ZGJTRKaR8jbdtSkmMQOgDLon4ggCghaWB
H+2hTK+ctTD8HLujdPbKKzc=
=KW8k
-END PGP SIGNATURE-

Re: make distcheck fails for simple Makefile.am

[Ralf Wildenhues]

* Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST:
> 
> In a simple Makefile.am:
> 
> pamdir = /etc/pam.d
> pam_DATA = schroot
> EXTRA_DIST = $(pam_DATA)
> 
> make distcheck fails:

Make that 
  pamdir = $(prefix)/etc/pam.d

but you really should be using sysconfdir:
  pamdir = $(sysconfdir)/pam.d

so that both the casual user and the distribution packager can easily
override the values: the former could do
  configure --sysconfdir=/etc   # rest goes under /usr/local
whereas the latter does
  configure --prefix=/

So no, this is not a bug in Automake.

Regards,
Ralf