On Tue, Jan 06, 2004 at 10:14:09PM -0500, Michael B Allen wrote:
| > Back when I used RedHat I always found it to be a pain the way you
| > have to manually track down, and rebuild, package depedencies.
| >
| > | So I thought I'd try debian as it seems a little more consistent.
| > | Is this true?
| >
| > Debian includes all of its packages in one place, and automatically
| > builds all of them. Using apt (aptitude is a good visual front-end)
| > you won't have to track down dependencies of a given package when you
| > install or upgrade.
| >
|
| However, from reading the APT HOWTO it does not appear to be easy to
| escape the dependency system.
Well, true. You wouldn't want to have a program installed without all
of the necessary libraries and such because it wouldn't run then. The
difference is the amount of manual effort that goes into satisfying
dependencies.
| For example, I need to install postfix SASL + TLS for SMTP_AUTH which is not
| supported by default. You need to create custom packages.
The base 'postfix' package doesn't have SASL or TLS. However, the
postfix-tls package has both. So the correct answer is
# aptitude install postfix-tls
to add TLS and AUTH support to the installed postfix package.
| On Redhat I used the following description:
|
| http://postfix.state-of-mind.de/patrick.koetter/smtpauth/
|
| I just removed the existing MTA, built new RPMs with the right options and
| installed them ignoring whatever dependecy other packages may have had.
With debian you would usually follow this procedure to make minor
variations on an existing package:
# aptitude install fakeroot
fakeroot is a great tool for fooling a build system into
thinking it is root when it isn't (so that permissions and
stuff are correct on built files)
# apt-get build-dep postfix
this is to install all -dev packages and what-not the
build system may need for this package
$ apt-get source postfix
Get the source that the debian package was built from
$ cd postfix-2.0.16
(the newly created directory containing the source)
$ $EDITOR ./debian/rules
Here you edit the rules for building the package, such as
altering config options and the like.
You can even edit the source to apply some patch or to
make a modification of your own.
$ $EDITOR ./debian/changelog
Create a new entry and bump the version number slightly
(eg change 2.0.16-1 to 2.0.16-1.1)
$ fakeroot ./debian/rules binary
# cd ..
# dpkg -i postfix_2.0.16-1.1_i386.deb
(whatever the full file name ends up being, I'm too lazy
to derive it now and ought to be sleeping :-))
This may look daunting at a first glance, but really it isn't quite
simple and straightforward. (assuming you don't create any build
errors while you edit the source) In doing this, you haven't created
any dependency problems at all. The new package drops in place as an
upgrade to the existing one (from the debian repository). The new
custom package fulfills all the dependencies it is supposed to.
| If I use debian it sounds like using custom packages is more
| difficult. I'll have to create a file with equivs-contol and then
| edit it. That's not so bad but knowing what to put in it bothers me.
equivs is another option. Use equivs if you want to merely trick the
package system into thinking you have such-and-such dependency met.
This is most useful if you want to build something from source (eg a
brand new MTA (such as exim 4, almost 2 years ago when debian didn't
have it)) and need to tell the package system about it. I have used
equivs on occaision.
To determine what you need in the "fake" package generated by equivs,
just look at what dependencies it is supposed to fulfill. The file
format for debian "control" files is really quite simple and
straightforward and basic usage can be picked up simply by reading
other control files (in fact, that's the most I've done with them).
The syntax is just like output from 'apt-cache show' and very similar
to what aptitude shows for a package's detail.
HTH,
-D
--
Micros~1 :
For when quality, reliability
and security just aren't
that important!
www: http://dman13.dyndns.org/~dman/ jabber: dman@dman13.dyndns.org
Attachment:
signature.asc
Description: Digital signature