[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: yum and rpm packaging

On 10/24/2009 03:13 AM, Richard Ryniker wrote:
A couple of years ago, I was so frustrated by multiple, failed attempts
to build applications because some<your_name_here>-devel package had not
been installed that I wrote a program to iterate over every installed
package name and report any matching, uninstalled "-devel" package
available in a repository.  After I told yum to install all those
1. you had serious overkill
2. if you didn't have the 'base' package installed, you still didn't get the needed -devel package installed to build your app.

RPM is about reproducible package building. To this end, it gives the opportunity to list both runtime and build time requirements. Usually an upstream author will (should) mention, in some text note, that to compile her program, install x,y,z

The .spec formalizes this. It doesn't help when that upstream note missed things.

The Fedora build systems (via mock) enforce this by preparing a chroot that contains only the build-requires written into the spec. If the package fails to build you haven't included all requires yet.

Additionally, if the package builds but didn't have some optional capabilities, then a build requires might be missing for that optional feature.

One place useful information might be added, without risk of
instability, is in package descriptions.  For example, F12 moved GNOME
preferences for windows from the control-center package into a
control-center-extra package.  If some pointer had been put into the
description for control-center, users might have an easier time to
learn this - especially if this sort of track were provided often so
one easily learned to look for it.  (The F12 Release Notes lists
control-center-extra, but says nothing about why it exists.)  If we
The RPM packager can already do this, by adding provides in the package. When a tool like yum whatprovides /x/y/z or a capability, the package that provides it is returned. Usually, the new package also provides an obsoletes (with version), to inform package managers that this new package takes over some roles of the original package.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]