I hate deploying anything on a RedHat machine that isn't part of an RPM, so
I've started working on Asterisk-related RPMs. So far I've modified the
zaptel build environment (mostly zaptel/Makefile) in to build a zaptel RPM,
and I'd like to submit my changes for review and inclusion into CVS.
Objectives:
- Add an 'rpm' target to zaptel/Makefile to build a Redhat RPM.
- Modify the zaptel build so that the RPM and a normal 'install' can be
built with the same code, and, where appropriate, as a non-root user.
Summary of Changes:
- Broke up the 'install' target into two pieces, 'install-files' and
'post-install', corresponding to the RPM '%install' and '%post' sections.
All of the 'mknode' calls, modules.conf munging, ldconfig calls, and
chkconfig calls, etc. -- which require root access -- are done by
'post-install'. Moreover, since the build environment is not available at
%post execution time, I had to move all of the 'post-install' stuff into a
'ztpost' script, which gets installed as part of the RPM.
- Defined RPMVERSION and RPMRELEASE variables in the Makefile
- Added -DCONFIG_ZAPATA_NET to KFLAGS automatically, based on a test for
hdlc.h in the kernel source tree. (Note: see Questions below)
- Build sethdlc automatically, using same test above.
- Added $(SETHDLC) to 'all' target
- Added 'ztpost' target to build ztpost script from ztpost.in template file.
Moved all of the device construction and other post-installation code into
this script.
- Added 'zaptel.spec' target to build zaptel.spec from zaptel.spec.in
template
- Added 'rpm' target to build zaptel RPM. This requires no root access, so
long as your rpm build and source trees are accessible. (Usually by defining
%_topdir and %buildroot in ~/.rpmmacros.) (I was just thinking, though, that
it shouldn't be too difficult at all to do the entire build in a tmp
directory.)
Questions:
- In my particular situation, I needed to build with
KFLAGS+=-DCONFIG_ZAPATA_NET and also build 'sethdlc' to get hdlc support. I
noticed zaptel builds fine with this defined, even w/no hdlc support in the
kernel. So, is it safe to leave it defined all the time? If not, what's a
good test for automatically defining it if hdlc is enabled in the kernel?
My test for automatically defining CONFIG_ZAPATA_NET or not currently fails.
I have successfully installed and tested the RPM, but only on an
hdlc-enabled machine. I've attached a tarball of my Makefile,
zaptel.spec.in, and ztpost.in. I'd appreciate any help on the above and any
suggestions for improvement.
Posted: Sun Apr 06, 2003 5:47 pm Post subject: [Asterisk-Dev] zaptel rpm submission
Quote:
- Broke up the 'install' target into two pieces, 'install-files' and
'post-install', corresponding to the RPM '%install' and '%post' sections.
Okay, so long as none of this breaks the existing normal behaviors.
Quote:
All of the 'mknode' calls, modules.conf munging, ldconfig calls, and
chkconfig calls, etc. -- which require root access -- are done by
'post-install'. Moreover, since the build environment is not available at
%post execution time, I had to move all of the 'post-install' stuff into a
'ztpost' script, which gets installed as part of the RPM.
Hrm... Is there a way to "fix" that?
Quote:
- Defined RPMVERSION and RPMRELEASE variables in the Makefile
Fine :)
Quote:
- Added -DCONFIG_ZAPATA_NET to KFLAGS automatically, based on a test for
hdlc.h in the kernel source tree. (Note: see Questions below)
No-can-do... hdlc support is not, by default, built in a redhat
kernel.
Quote:
- Build sethdlc automatically, using same test above.
- Added $(SETHDLC) to 'all' target
I think sethdlc fails to compile on some systems, not because the header
isn't there, but because it is different somehow. Perhaps we can make it
default in your RTP target?
Quote:
- Added 'ztpost' target to build ztpost script from ztpost.in template file.
Moved all of the device construction and other post-installation code into
this script.
Hrm okay.
Quote:
- Added 'zaptel.spec' target to build zaptel.spec from zaptel.spec.in
template
Yah.
Quote:
- Added 'rpm' target to build zaptel RPM. This requires no root access, so
long as your rpm build and source trees are accessible. (Usually by defining
%_topdir and %buildroot in ~/.rpmmacros.) (I was just thinking, though, that
it shouldn't be too difficult at all to do the entire build in a tmp
directory.)
I dunno, I try to stick with pretty conventional stuff in the Makefiles
whenever I can, since it makes it easier to maintain.
Quote:
- In my particular situation, I needed to build with
KFLAGS+=-DCONFIG_ZAPATA_NET and also build 'sethdlc' to get hdlc support. I
noticed zaptel builds fine with this defined, even w/no hdlc support in the
kernel. So, is it safe to leave it defined all the time? If not, what's a
good test for automatically defining it if hdlc is enabled in the kernel?
My test for automatically defining CONFIG_ZAPATA_NET or not currently fails.
You could check in /boot/System.map but that's somewhat specific to
RedHat.
Posted: Sun Apr 06, 2003 6:38 pm Post subject: [Asterisk-Dev] zaptel rpm submission
On Sun, 2003-04-06 at 12:47, Mark Spencer wrote:
Quote:
> - In my particular situation, I needed to build with
> KFLAGS+=-DCONFIG_ZAPATA_NET and also build 'sethdlc' to get hdlc support. I
> noticed zaptel builds fine with this defined, even w/no hdlc support in the
> kernel. So, is it safe to leave it defined all the time? If not, what's a
> good test for automatically defining it if hdlc is enabled in the kernel?
> My test for automatically defining CONFIG_ZAPATA_NET or not currently fails.
You could check in /boot/System.map but that's somewhat specific to
RedHat.
Actually the file is stock for the kernel. Where it is located depends
if you use "make install" in the kernel source and where the
INSTALL_PATH is set.
> - Broke up the 'install' target into two pieces, 'install-files' and
> 'post-install', corresponding to the RPM '%install' and '%post'
sections.
Okay, so long as none of this breaks the existing normal behaviors.
No, it doesn't, but I need to pull the CONFIG_ZAPATA_NET define back out of
the normal build. Probably the simplest thing to do is define two targets,
'rpm' and 'rpm-hdlc', to build without or with hdlc support.
Quote:
> All of the 'mknode' calls, modules.conf munging, ldconfig calls, and
> chkconfig calls, etc. -- which require root access -- are done by
> 'post-install'. Moreover, since the build environment is not
available at
> %post execution time, I had to move all of the 'post-install'
stuff into a
> 'ztpost' script, which gets installed as part of the RPM.
Hrm... Is there a way to "fix" that?
I don't think there's really anything to fix. Editing of modules.conf must
be deferred until rpm install time on the client machine. The same is true
for the calls to ldconfig, chkconfig, depmod, etc. The calls to mknode
could be performed at RPM build time, if run as root, but why bother, since
not everything can be done then, anyhow. (Plus, it's a good idea to be able
to build everything as non-root.)
So, since some stuff must be deferred until the rpm is installed, those
post-install steps need to make their way into the spec file. Since we also
want to keep them available to the standard 'make install' command and also
not replicate code unnecessarily, I'm kinda stuck with putting them into a
shell script that'll work in both situations.
Quote:
> - Added -DCONFIG_ZAPATA_NET to KFLAGS automatically, based on a test for
> hdlc.h in the kernel source tree. (Note: see Questions below)
No-can-do... hdlc support is not, by default, built in a redhat
kernel.
> - Build sethdlc automatically, using same test above.
> - Added $(SETHDLC) to 'all' target
I think sethdlc fails to compile on some systems, not because the header
isn't there, but because it is different somehow. Perhaps we can make it
default in your RTP target?
Okay, hows this? I just defined two targets, 'rpm' and 'rpm-hdlc', to build
an rpm without or with hdlc support.
Quote:
> - Added 'rpm' target to build zaptel RPM. This requires no
root access, so
> long as your rpm build and source trees are accessible.
(Usually by defining
> %_topdir and %buildroot in ~/.rpmmacros.) (I was just thinking,
though, that
> it shouldn't be too difficult at all to do the entire build in a tmp
> directory.)
I dunno, I try to stick with pretty conventional stuff in the Makefiles
whenever I can, since it makes it easier to maintain.
No problem. I'll leave it as is.
Quote:
You could check in /boot/System.map but that's somewhat specific to
RedHat.
It also assumes that you're building against the same kernel you're running
on the build machine.
Attached is an updated tarball of
zaptel/{Makefile,zaptel.spec.in,ztpost.in}.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum