2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>: > If you feel you can talk about a potential PM candidate for LFS, please > write up a document that outlines the following:
OK, deb--in my opinion, not a candidate at all. But let's have it just for comparison. > - it's strengths and weaknesses + well-tested in Debian and its derivatives, as well as in the OpenZaurus project - dpkg depends on itself in order to build successfully (workaround: before building dpkg, create a shell script called "dpkg" that prints the correct information when called with the "--print-architecture" flag, and place it into $PATH). - Due to this missed self-dependency and the recommendation to use the official Debian repository, the existing apt hint is broken beyond repair and has to be removed. The idea is that "nobody was able to make it work with LFS". - one has to build dpkg, debconf, debhelper, and all of their dependencies just to be able to build Debian packages with the canonical "debian/rules binary" command. If one wants to work with repositories, too, he has to install libapt and apt-get (or its alternative, aptitude). That's doable, but, IMHO, too much for Chapter 5. + It has all features that one expects from a working package manager, e.g., sane handling of the configuration files and dependency checking. If one installs the "ucf" package, it is even possible to merge the upstream changes into locally modified configuration files (of course, there is a chance to view the result during the installation and adjust it as needed). + It allows to build the package as non-root, and run only the actual package installation command (dpkg -i) as root. I.e., the correct permissions are stored in memory by the "fakeroot" command (that has to be installed from a separate package). * Debhelper allows some predefined steps to be taken (e.g., stripping, compression of man and info pages, but not catching obvious errors such as /usr/etc and UTF-8 encoded manual pages) on a per-package basis. To do so, explicit calls to debhelper must be placed in the debian/rules file. + It manipulates binary packages, with obvious benefits like the ability to deploy them, to revert to the old version quickly, and so on. + Apt allows creation of repositories, and aptitude remembers which binary packages are explicitly requested, and which are installed in order to satisfy dependencies. Unfortunately, there is no way to say "I installed libfoo-dev only to build and package bar and don't need it otherwise". - Packaging and build instructions are in multiple files in the "debian" directory. To write them, one has to know the Debian policy (i.e., how the official build daemon will call debian/rules), and how to call debhelper for various tasks such as finding shared library dependencies. Debian packaging scripts are verbose, not easy to write from scratch, and many people even inside Debian often use another already-debianized package as a template. + It automatically finds out runtime library dependencies, as well as runtime dependencies on Perl and Python modules, if told to do so by placing a call to "dh_shlibs", "dh_perl" and "dh_python" programs (from debhelper) into debian/rules (or use CDBS, see below). + It is buildsystem-independent, but one can take advantage of autoconf and other common buildsystems by installing the "cdbs" package or something similar. If CDBS is used, a debian/rules file for a CMMI package that also wants the --with-ipv6 option simplifies down to this: #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk DEB_CONFIGURE_EXTRA_FLAGS := --with-ipv6 - (as one can see from the above example, there is no 1:1 correspondence between CDBS instructions and non-PM instructions, so they can't be autogenerated) - (as one can see from the example above, there is much more than one way to debianize a package, this will lead to disagreements what to choose) - The user has to learn a lot beyond the basic bash syntax in order to understand the existing debian/rules files (i.e., know all debhelper options). Worse, if some "debianization aid" such as "yada" is used (it plays a role similar to CDBS), and someone has to fix a bug in a package not maintained by him, discussions such as "yada expert is needed" are common on Debian mailing lists. + Text-based database > - why it's better than other candidates It isn't. > - why it's worse than other candidates See above. > - what it takes to integrate it in the LFS book As a minimum, install dpkg, debhelper, and all their dependencies. Write debian/rules files (they are just Makefiles) that install the package into DESTDIR, and call debhelper as needed. Optionally, write the list of installed files for each binary package into packagename.install files (the other alternative is to call dh_install or dh_move with the exlicit arguments what to move to a different package). List configuration files. > - what it likely is not able to do for its users It can do everything with the right optional dependencies installed. > - how well it can deal with matters such as conflict resolution and > dependency handling Same as RPM or better. The "optional runtime dependency" stuff (aka recommendations and suggestions) is not likely to be used by LFSers, because it is useless without a repository. Neither RPM nor DPKG have "optional build-time dependencies", and Debian has a release goal of 100% reproducible builds (for the purposes of securty rebuilds) even when wagonloads of potentially useful packages are installed (so that, e.g., an upload by the security team never switches the dependency from expat to libxml2 if a package can use either of them). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
