Gerard Beekmans wrote: > If you feel you can talk about a potential PM candidate for LFS, please > write up a document that outlines the following:
Slackware-like .tgz > - it's strengths and weaknesses + It is very simple, and everybody is expected to understand the code. - Out of the box, it requires tar-1.13 due to the reasons outlined in ftp://ftp.slackware.com/pub/slackware/slackware_source/a/tar/tar.SlackBuild (that are, IMHO, invalid--you should use ext3 on LVM2 and never have problems with free disk space). Anyway, this requirement is easy to patch out. + It has no external dependencies except dialog (which is optional and depends only on ncurses anyway). - It has no features one expects from a sane package manager, such as dependency checking. To work around this, the Slackware installer recommends installing all packages from the DVD. * Configuration file handling is emulated with post-installation scripts, by renaming the packaged copies to *.new and using code such as ftp://ftp.slackware.com/pub/slackware/slackware_source/a/udev/doinst.sh - Packages have to be built as root (workaround: install fakeroot from Debian). - No checking of the package contents is possible unless one patches the makepkg script. + It manipulates binary packages, with obvious benefits like the ability to deploy them, to revert to the old version quickly, and so on. + Packaging and build instructions are in one file, with the .SlackBuild extension. Such files are very easy to write from scratch, because they are just bash scripts. + It is buildsystem-independent. - Instead of SlackBuild scripts, there is a temptation to produce Slackware packages with checkinstall--but this will clobber configuration files. - It comes from Slackware, against which I have prejudice (they oversimplify a lot of things). + Text-based database > - why it's better than other candidates Because it is very simple. > - why it's worse than other candidates Because it is only a toy model of a package manager. It can only install packages by untarring the archive and running the install/doinst.sh.script, uninstall them, and list packages claiming ownership of a file. It cannot explain why each package is needed in the system, and doesn't prevent its removal when in fact there are other packages depending on it. > - what it takes to integrate it in the LFS book > * not looking for installation instructions. Just explain the impact > and changes that will be required for successful use Write SlackBuild scripts: this means DESTDIR, post-installation steps, and, for each configuration file, renaming it by adding the .new extension and writing a scriptlet like ftp://ftp.slackware.com/pub/slackware/slackware_source/a/udev/doinst.sh > - what it likely is not able to do for its users Any kind of dependency tracking. > - how well it can deal with matters such as conflict resolution and > dependency handling It can't, by design. Upgrading a package means: 1) Installing a new version, so that it overwrites some old files. At this point, _two_ packages (old and new) will claim ownership of some files. 2) Deleting the old version, so that files that existed only in the old version get deleted because their reference count drops to zero. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
