2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>: > The more we discuss it, the more PM becomes a focal point. I agree with > Greg Schafer in that the actual choice of PM is a user's choice in the > end and shouldn't matter.
Correct. > About all we should attempt to do is inform the user of all the main > stream and (perhaps) some of the not-so-mainstream options out there. Currently we do exactly that on the http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkgmgt.html page--yet it is useless, because one of the mainstream methods of package management (DESTDIR-based) currently requires a lot of deviation, and nothing is done to cover the topics of handling configuration files and distributing the packages, if applicable. > We need a clearly defined list of pros, cons and technical explanations > plus their limitations of each viable choice - all the information that > a user needs to make an informed decision while keeping in mind that > some of these programs may never have been used (or heard of) before. So > we can't assume a basic working understanding of the programs. Correct. > Having said that, we will probably get to a scenario where we need to > settle on something we will be using ourselves for the LFS project. For > instance, the LFS server itself will eventually be outfitted with one of > the results of this process. This wouldn't be an endorsement, but will > probably be perceived as such - "if the LFS developers use > implementation X on the LFS server and to develop the LFS project itself > with, then I should probably use it as well." There is another argument. If there is no package manager in the book that is required to be used by the editors (just some allegedly PM-aware instructions), they will continue using the "it's all in my head" principle and will have no motivation to check the modifications supposed to make their pages PM-aware. > One could consider embarking on a mission to make all the PM options > talk to each other so you can mix and match what PM you use at any given > time - you can switch from deb to rpm to something else on the same > system on-the-fly. That would be an interesting challenge in itself. Database conversion is, indeed, not a trivial task. > Alexander started a thread about an RPM Proof Of Concept. I quickly > glanced at it and it seems an installation HOWTO, not including the > information I mentioned above that we need more than the installation > itself right now. The idea was to say something concrete. This is, of course, just a skeleton, that has to be wrapped into some nice textual instructions and explanations. We can't have the description of the build procedure without something to describe. See also my "Format for the future LFS" mail. > If you feel you can talk about a potential PM candidate for LFS, please > write up a document that outlines the following: OK, let me start by talking about RPM 5.0.x, as released on http://rpm5.org/. Note that this information doesn't apply to RPM 4.x, as released on http://www.rpm.org/, i.e., there are two projects with the same name and I am talking only about one of them. Also note that I don't think it is the best alternative, I have not explored Pacman enough to choose between them. > - it's strengths and weaknesses + It (or its sibling, RPM 4.x) is used in a number of distributions and thus receives a lot of testing. + It doesn't need a lot of external dependencies, and is simple enough for a user to submit a working hint in the past. + It has all features that one expects from a working package manager, e.g., sane handling of the configuration files and dependency checking. + It allows to build the package as non-root, and run only the actual package installation command (rpm -ivh) as root. I.e., the correct permissions are specified in the spec file. + It allows arbitrary steps to be taken (e.g., stripping, compression of man and info pages, catching obvious errors such as /usr/etc and UTF-8 encoded manual pages) automatically before creating a binary package + 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 .spec extension. Such files are easy to write from scratch + It automatically finds out runtime library dependencies, as well as runtime dependencies on Perl and Python modules, and shell scripts used durung post-install steps. - It historically comes from RedHat and thus many people have prejudice against it - It has a lot of legacy features that were oriented to the old versions of autoconf (see, for example, how the %makeinstall macro expands--BTW RedHat doesn't use this macro) - The user has to learn a bit beyond the basic bash syntax in order to understand the existing spec files (i.e., know how various %{things} expand) - Some stock post-processing scripts contain small (i.e., ignorable) bugs, but I'll raise the known ones upstream. - The %configure macro interferes (ore, more correctly, duplicates or overlaps in functionality) with config.site files, but the autogenerated spec files are not expected to use this macro, so this is likely to be a non-issue. However, in this case, setting the default CFLAGS from RPM macros, as documented, will stop working. - Binary database - Embeds many third-party projects like Berkeley DB and the Lua scripting language. > - why it's better than other candidates Because Dan Nicholson has a lot of working spec files and thus the initial "proof of concept" implementation of an LFS-like system with the RPM package manager already exists. > - why it's worse than other candidates Because of the "%configure" vs "./configure --prefix=/usr" issue. "%configue" means that the paths will be different as compared to the non-PM version of LFS, and that config.site files won't work. "./configure" allows to achieve exactly the same result as the current LFS, at the cost that the %{optflags} no longer sets the default CFLAGS, contrary to its documentation. > - what it takes to integrate it in the LFS book > * not looking for installation instructions. Just explain the impact DESTDIR, post-installation steps, list of files whose MD5 sum can change during the normal operation of package (e.g., for glibc, that's /usr/lib/locale/locale-archive, because glibc provides the "localedef" command that modifies this file), list of files that should not be replaced on upgrades (aka configuration files). All of that goes into spec files, that also specify how to split the package into the main and -devel parts. This split is necessary with any binary package manager that doesn't allow two packages to have the same file, in order to allow gradually upgrading, say, from libreadline.so.5 to the future libreadline.so.6 without removing everything. > and changes that will be required for successful use > - what it likely is not able to do for its users It doesn't track which packages were explicitly asked for, and which were installed only as dependencies. IOW even if someone writes a full tree of build-time dependencies, RPM won't be able to use it in order to automatically "install xfce" from source. > - how well it can deal with matters such as conflict resolution and > dependency handling It doesn't allow two packages to have the same file. It tracks dependencies of binary packages, and doesn't allow breaking them by default. Moreover, often it finds the library dependencies automatically. Source build-time dependencies have to be specified manually. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
