On Fri, Oct 03, 2003 at 08:01:40AM +0200, Matthias Kurz wrote: > Well, there is a difference between "rpm --whatrequires" and > "openpkg build -L".
rpm inspects the local database of installed packages. openpkg build inspects the repository index. openpkg build also manages reverse dependencies. A simple: openpkg build openssl will rebuild all installed packages that depend on openssl The -L option is a feature for a repository maintainer to find out what packages might be affected without actually having these packages installed (which might be even impossible due to conflicts). > That different output is generated for two consecutive calls with the > _same_ option(s) doesn't make things easier. If the output changed then either the installed packages changed or the index changed. > - Install packages and all packages they depend on from source rpms > - Install packages and all packages they depend on from binary rpms There is no real distinction between source and binary rpms in a repository. Binary rpms are not built but copied and sources are sometimes required. Otherwise it is simply: openpkg build -p platform package-name The index determines wether a binary RPM or a source RPM is used but only binary RPMs that match the platform are selected. > - Upgrade all installed packages from source rpms when necessary What is 'necessary' ? > - Unconditionally upgrade all installed packages from source rpms openpkg build -a > - Upgrade specific packages from source rpms when necessary Again, what is 'necessary' ? > - Unconditionally upgrade specific packages from source rpms (*2*) openpkg build package-name > - Upgrade all installed packages from binary rpms when necessary > - Unconditionally upgrade all installed packages from binary rpms openpkg build -p platform -a > - Upgrade specific packages from binary rpms when necessary > - Unconditionally upgrade specific packages from binary rpms openpkg build -p platform package-name > Are all those cases supported ? Except for the notion of 'necessity' these are the trivial cases. > Are there other important/supported cases ? > What are the recommended (openpkg) commands for the supported cases ? Many. The most common case is: install/upgrade a package and upgrade all dependencies first to ensure that the basis for the installed/upgraded package is up-to-date: openpkg build -U package-name or for all installed packages: openpkg build -U -a Then you may want to rebuild an already installed package: openpkg build -g package-name Do the same, but also rebuild all the dependencies: openpkg build -z package-name Rebuild all installed packages (often required after a system upgrade): openpkg build -z -a > It is also _extremly_ important to _define_(*3*) what effect --force has > on configurations. I believe that's clearly defined by RPM. The packages have to declare what the configuration is of course. > place. E.g. httpd.conf et al are not flagged as config files in the apache2 > package - and are consequently replaced by an upgrade. D'oh ! It should be replaced (and saved) only when the default httpd.conf changes. Otherwise it is a bug. > I have machines with up to 240 installed packages - i really do not want > to check each and every configuration after a "minor" upgrade. One problem is: what is a 'minor' upgrade. Nobody can guarantee that an upgrade does not require changes in the configuration. You absolutly must verify the configurations. RPM treats changes in the default configuration of a package as a 'major' upgrade. In that case it saves the old config file and stores the new config file. The OpenPKG rc script will warn you when a saved configuration file exists and should refuse to start a package in that case. There are often config files that change just for a new CVS version number or datestamp, sometimes a simple three-way-merge could generate a valid script. But no generic automated system will be smart enough to ignore such harmless changes. For a large installation I also prefer to keep all configuration files at a central place (CVS archive or something similar) and deploy them on the systems (e.g. with cfengine). The deployment procedure can (and should) check for changed configurations. > > > But when i try this with binary packages > > > openpkg build -p <platform> > > > -r ftp://bla/.../RPM/PKG > > > -f ftp://bla/.../RPM/PKG/00INDEX.rdf.bz2 > > > -i -g -u > > > I get > > > FATAL: cannot find source for 'openssl' > > > > > If your command listing above is complete it looks like you forgot to > > create a new index. > > It works, when i leave out the "-u", so i do a -u says that you do not want to use binary RPMs, unfortunately that also rules out binary RPMs from the index. You can call that a bug. > "rm $opkg_root/RPM/PKG/*; openpkg build ..." This should be a sufficient workaround. > (*2*) Well, "unconditionally" here means: force a rebuild of only the named > packages and also force a rebuild of all packages that depend on one > or more of the rebuilt packages. That's called 'reverse dependencies' and is handled automatically unless you turn it off with -q. You may want to turn it off if you upgrade a build tool like gcc or make. It is implicitely turned off for the openpkg bootstrap package itself, otherwise an upgrade to the bootstrap would rebuild every installed package :-) Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
