Re: Differences of Debian vs. the Other Guys
Hi,
Well, there are a number of things, but the following are
important (in no particular order)
1) strong dependency tracking. Espescially with APT, the next
generation replacement for dselect, packages are unpacked in an
order that minimizes the time for which a package is unavailable
during upgrades, packages may be held back if the dependecies are
not filled. Conflicts: headers ensure that packages that may
damage each other by being simultaneously installed are not ever
on the same machine.
2) co-operation between packages and systems integration:
a) the menu package (highjly flexible, with local overrides
possible)
b) the web standard This makes possible things like
o) HTMLified documentation like http://localhost/doc/ and others
o) standard location of the document root and cgi-bin makes
it possible for packages to integrate themseles on the
local http server
c) kernel modules can be compiled while you are compiling the
kernel so that they are in sync
3) install info, mime, and sgml tools help ensurte that all packages
make full use of the info facility, and all SGML packages are
available to SGML tools
4) Maintianer pre-post installation scripts -- look at
sendmailconfig. It makes configuring _sendmail_ a breeze.
5) make-kpkg (from the kernel -package package -- look at
/usr/doc/kernel-package/Rationale.gz as to the benefits of using
it)
6) The Policy documents, and adherence to standards.
7) modular configuration of wondow managers like fvwm2 (one may have
a very nice fvwm configuration with any amount of local ovber
rides)
8) Shared libraries (dpkg-shlibs and friends) I can have multiple
versions of the same library installed at once on Debian.
9) kernel flavours -- I can have multiple fkavours of the same kernel
on my machine and not worry about the modules
10) The configurations for each installed kernel are stored in /boot
11) package upgades have a text based user interface (not everyone has
X, you know)
We are working on things like pre-fabricateed package
selections (so one may select power-user or web-development or gaming
or code-development and get a selection of relevant packages and
defaults); we are investigating linuxconf.
rpm vs dpkg
- Dpkg uses `make' to drive the packaging process, which is running
rings around the semi-shell-script type of stuff that RPM is
using. For instance, in dpkg you can set a global variable at the
beginning and use it throughout the rules file. In RPM (at least
when I was working with it, you needed to use macros, which had
limitations. You can also override variables at the command line.
- In dpkg, you can include you own custom fields, and even have them
show up when inspecting the package later. I was experimenting with
adding CVS control information to our RPM setup. I ended up having
to define macros in the rpm file and have a shell-script extract the
values of these. I would much rather have extended the set of
package control fields.
- Dpkg uses a directory of control information. RPM forces you to jam
all information into one big file. Apart from the lack of joy in
editing large files with loads of unrelated information, it is also
much easier to add you own custom extra pieces of information in a
debian package. Just add another file to the debian directory. Dpkg
will not care.
- RPM depends on magic macros such as %setup which is used to unpack
the source. You can have several %setup's but there is a hidden
variable that remembers the resulting directory of the last %setup
issued, which affects later sections.
- In order to have RPM build a .rpm file, you need to run all steps in
one go. That is you need to unpack the source, compile and
package. You cannot at the end of a busy debugging session, just
pack up the binaries lying all ready in your work directory. You
need to remove it, and go from the top. Again, dpkg is much more
flexible.
- RPM does not have something like dpkg-shlibs.
- (Probably not correct) RPMs package format is more complicated than
the dpkg one. I do not know of a way to extract the files from an
RPM package, without using the `rpm' tool. The .deb files are just
`ar' archives containg a tar file.
- The unconditional need to exhaustively declare all files that is to
go into the RPM file. Usefull for the control freak but hell for the
quick-and-dirty practioner in the initial stages of creating a
package, especiallly given the need to recompile everytime you is to
create a package.
Advantages of using make-kpkg
---------- -- ----- ---------
I have been asked several times about the advantages of using
the kernel-package package over the traditional Linux way of hand
compiling kernels, and I have come up with this list. This is off the
top of my head, I'm sure to have missed points yet. Any additions
welcomed.
i) Convenience. I used to compile kernels manually, and it
involved a series of steps to be taken in order;
kernel-package was written to take all the required steps (it
has grown beyond that now, but essentially, that is what it
does). This is especially important to novices: make-kpkg
takes all the steps required to compile a kernel, and
installation of kernels is a snap.
ii) It allows you to keep multiple version of kernel images on
your machine with no fuss.
iii) It has a facility for you to keep multiple flavours of the
same kernel version on your machine (you could have a stable
2.0.33 version, and a 2.0.33 version patched with the latest
drivers, and not worry about contaminating the modules in
/lib/modules)
iv) It knows that some architectures do not have vmlinuz (using
vmlinux instead), and other use zImage rather than bzImage,
and calls the appropriate target, and takes care of moving the
correct file into place.
v) Several other kernel module packages are hooked into
kernel-package, so one can seamlessly compile, say, pcmcia
modules at the same time as one compiles a kernel, and be
assured that the modules so compiled are compatible.
vi) It enables you to use the package management system to keep
track of the kernels created. Using make-kpkg creates a .deb
file, and dpkg can track it for you. This facilitates the task
of other packages that depend on the kernel packages.
vii) It keeps track of the configuration file for each kernel image
in /boot, which is part of the image package, and hence is
the kernel image and the configuration file are always
together.
viii) It allows to create a package with the headers, or the
sources, also as a deb file, and enables the package
management system to keep track of those (and there are
packages that depend on the package management system being
aware of these packages)
ix) Since the kernel image package is a full fledged Debian
package, it comes with maintainer scripts, which take care of
details like offering to make a boot disk, manipulating
symbolic links in / so that you can make boot loader scripts
static (just refer to the symbolic links, rather than the real
image files; the names of the symbolic links do not change,
but the kernel image file names change with the version)
x) There is support for the multitudinous sub architectures that
have blossomed under the umbrella of the m68k architecture.
xi) There is support there for optionally applying patches to the
kernel provided as a kernel-patch .deb file, and building a
patched kernel auto-magically, and still retain an UN-patched
kernel source tree
Disadvantages of using make-kpkg
------------- -- ----- ---------
i) This is a cookie cutter approach to compiling kernels, and
there are people who like being close to the bare metal.
ii) This is not how it is done in the non-Debian world. This
flouts tradition. (It has been pointed out, though, that this
is fast becoming Debian tradition)
iii) It forces you to use fakeroot or sudo or super or be root to
create a kernel image .deb file (this is not as bad as it
used to be before fakeroot)
manoj
--
"Look! There! Evil!.. pure and simple, total evil from the Eighth
Dimension!" Buckaroo Banzai
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: