Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#13879 closed enhancement (fixed)

at-3.1.23 has a bogus sed and autoconf

Reported by: ken@… Owned by: ken@…
Priority: normal Milestone: 10.0
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

At is an old package which does not support non-root or DESTDIR installations. That makes it a bit harder to test.

At the moment we have a sed to fix up the docdir, which should end up using

docdir          = ${prefix}/share/doc/${PACKAGE_TARNAME}

But we override it during the install.

Using the sed and autoreconf, followed by configure with added '--prefix=/opt/testing' followed by a plain install without the overrides puts the docs into /opt/testing/share/doc.

In other words, the sed and autoreconf are useless.

Change History (9)

comment:1 by ken@…, 4 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

comment:2 by thomas, 4 years ago

Right. Looks like that is redundant as we have to override at 'make install' anyhow - otherwise we get the docs installed in ${prefix}/share/doc/at-x.y.z/at/ .

DESTDIR=/path is not supported but IROOT=/path (but still root required)

In my scripts i add

--with-jobdir=/var/spool/atjobs \
--with-atspool=/var/spool/atspool \

to configure so the

mkdir /var/spool/cron

can be dropped. I think '/var/spool/cron' is misleading since at has nothing to do with cron or even fcron.

I also had to add /etc/pam.d/atd containing

auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so

Btw, there is also a newer version than 3.1.23: http://software.calhariz.com/at/at_3.2.1.orig.tar.gz

in reply to:  2 comment:3 by Bruce Dubbs, 4 years ago

Replying to thomas:

Right. Looks like that is redundant as we have to override at 'make install' anyhow - otherwise we get the docs installed in ${prefix}/share/doc/at-x.y.z/at/ .

Agree.

In my scripts i add

--with-jobdir=/var/spool/atjobs \
--with-atspool=/var/spool/atspool \

to configure so the

mkdir /var/spool/cron

can be dropped. I think '/var/spool/cron' is misleading since at has nothing to do with cron or even fcron.

That seems reasonable. debian does that.

I also had to add /etc/pam.d/atd containing

auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so

That should be added to the book but we need to specify that the files is only needed if pam is installed.

Btw, there is also a newer version than 3.1.23: http://software.calhariz.com/at/at_3.2.1.orig.tar.gz

I don't know that we need to change. debian is still using 3.1.23 but arch is using 3.2.1. We probably need to investigate the differences.

comment:4 by Bruce Dubbs, 4 years ago

at 3.2.0 (2019-07-24):

   Print time of new job before the input of the commands, Closes 863045
   Do not drop seconds on -t option, Closes 792040
   Start using nice levels from 0 instead of 2. Closes 519716
   Correctly handle DST when specifying a UTC time. Closes 364975
   Add flag to send email to other user.

at 3.2.1~WIP+1

   Include config.h on parsetime.l 
   Check if libc provides __isleap() macro, see

The arch instructions are at https://github.com/archlinux/svntogit-community/blob/packages/at/trunk/PKGBUILD

comment:5 by ken@…, 4 years ago

Thanks to you both, particularly for the IROOT.

comment:6 by ken@…, 4 years ago

I'm copying the XML markup for the PAM file from xscreensaver, which has text explaining it should be done if built with PAM - but it looks to me as if jhalfs will run that automatically. Perhaps jhalfs pulls in the optional dependencies (PAM in this case).

comment:7 by ken@…, 4 years ago

Resolution: fixed
Status: assignedclosed

comment:8 by Pierre Labastie, 4 years ago

jhalfs for blfs puts PAM files in /etc/pam.d unconditionally. It does not prevent a non PAM system to run. And in case PAM has been installed, it generates the correct config.

More generally, config files that do not prevent a normal system to function are installed by jhalfs. Otherwise, there would be a lot of different "role"s, to indicate that a particular instruction is to be run if a package is (or will be?) installed. That wouldn't be useful.

jhalfs is for testing instructions, it is not guaranteed to build the system exactly as a user would build it (and even it is guaranteed not to :). When I use it for my own system, I very often have to edit build scripts.

in reply to:  8 comment:9 by ken@…, 4 years ago

Replying to pierre.labastie:

jhalfs for blfs puts PAM files in /etc/pam.d unconditionally. It does not prevent a non PAM system to run.

Thanks - my concern was that trying to create a file in a non-existent directory (/etc/pam.d) must result in error. In my own scripts I try to ensure that errors result in failure.

Note: See TracTickets for help on using tickets.