[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to rebuild from .deb sources (exim)



Ross Boylan <RossBoylan@stanfordalumni.org> wrote:

[Cc: line copied from previous post; sorry if you didn't actually want a
copy by mail.]

>I'm writing for two reasons: first, I'm a little unclear what exactly
>I should do once I succeed in rebuilding; second, I'm having some
>trouble getting the package to build.
>
>On the first point: is the proper procedure actually to build a new
>deb package and then install it over the existing one?

That's what I'd do, yes.

>How exactly do I do that?  And how do I avoid trouble when a new
>version of the package comes out?

Normally I mark it to hold in dselect and then repeat my changes each
time I see a new version. (And I file a bug report if I can and if it
makes sense so I don't have to do this too often. :))

>I think this is partly a question about what version number to assign
>the package.  I also don't see where to assign such a number.

Create a new entry in debian/changelog (from the top-level source
directory) with your version number. Installing devscripts and using
'debchange -v new-version-number' is probably the easiest way to get the
syntax right. I suggest that you increment the version number by a point
on the Debian revision part (after the -), so perhaps 3.12-10.1, or even
3.12-10.0.1 if you want to avoid running into any non-maintainer uploads
of the package.

>Also, I'm used to using apt-get or dselect to do my upgrades.  Do I do
>a dpkg --install with my new .deb?

Yep - or you could mimic the layout of the Debian archive and produce a
miniature apt-able archive of your own. You'll need to use
dpkg-scanpackages to produce the Packages file (and remember to gzip the
Packages file that it creates into Packages.gz; it wasn't at all clear
that this was necessary last time I did this).

>Or is this overkill, so that I could, for example, just drop the new
>binary in over the old one, without doing any of the packaging stuff?

You could, but I find it cleaner to package it; too often I don't notice
when a new version of a package arrives. exim has quite a lot of
binaries, too.

>Second, on the specifics of building the package: I did apt-get source
>and then tried debuild.  This failed because I didn't have
>libpcre2-dev installed (i.e., pcre.h was not found).  I've fixed that,
>but am still getting errors.

Do you also have all the -dev packages relating to the other libraries
on which exim depends (i.e. libc6-dev (I imagine :)), libident-dev, and
libopenldap-dev).

>I switched to debian/rules build from the top directory to simplify
>things and also commented out the rules line which does mkdir Local (it
>was failing since the directory now exists).

'debian/rules clean' (or 'debuild clean') should fix that.

>The make chugs along happily for awhile, but then I get
>gcc -c -O2 -g -Wall -I/usr/include/db1  plaintext.c
>/bin/rm -f auths.a
>ar cq auths.a b64encode.o b64decode.o call_pam.o xtextencode.o
>xtextdecode.o get_data.o md5.o cram_md5.o plaintext.o
>ranlib auths.a
>/bin/rm -rf ../drtables.o
>make[3]: Leaving directory `/usr/local/src/exim-3.12/build-Linux-i386/auths'
> 
>make[2]: *** No rule to make target `lookups/lookups.a', needed by
>`exim'.  Stop.
>make[2]: Leaving directory `/usr/local/src/exim-3.12/build-Linux-i386'
>make[1]: *** [go] Error 2
>make[1]: Leaving directory `/usr/local/src/exim-3.12'
>make: *** [build] Error 2
>
>Can anyone tell me what the problem is?  The complaint is especially
>weird since it just build auths.a.

Looking at the Makefile, it should build lookups.a some time before that
(before building directors, routers, and transports). Do you get any
errors at that stage?

Building lookups.a does depend on LDAP (see
build-Linux-i386/lookups/Makefile), so I'd guess that installing
libopenldap-dev will fix your problem.

>I'm running as an ordinary user on a current potato system.  I got
>most of task-devel, though I recall I did skip a few packages that
>seemed unnecessary.

task-debian-devel is useful, too, if you're planning to do this kind of
thing quite often. If nothing else, debian-policy, packaging-manual, and
maint-guide are supremely useful to have on your hard disk. :)

>P.S. Can anyone tell me what the story is with /etc/email-address,
>which I just noticed while poking around the source?  I didn't notice
>any mention of it in the docs.  Does it work?  Does it affect only
>mail heading to remote systesm?

It works fine, and yes. It's a Debian addition, and fairly simple, so I
guess the main documentation won't mention it.

-- 
Colin Watson                                     [cjw44@flatline.org.uk]



Reply to: