rpms/dynamite/devel dynamite.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Michael Schwendt]

On Fri, 26 Aug 2005 00:04:39 +0200, Matthias Saou wrote:

> Michael Schwendt wrote :
> 
> > On Thu, 25 Aug 2005 09:27:18 -0400, Andreas Bierfert wrote:
> > 
> > > Author: awjb
> > > 
> > > Update of /cvs/extras/rpms/dynamite/devel
> > 
> > > %package devel
> > > Group:          Development/Libraries
> > > Summary:        Files needed for software development with %{name}
> > > Requires:       %{name} = %{version}
> > 
> > Always exact %release here, too, so main package and -devel are
> > in sync _always_, especially for changes in API, ABI, feature set
> > or configuration settings.
> 
> I would tend to disagree here : A different release (almost?) never
> changes API, ABI or anything that could cause trouble. I myself prefer
> "%{name} = %{version}" because for someone who uses yum or similar it'll
> "just work" anyway, and for the poor soul behind a 9600bps modem,
> downloading the *-2 devel subpackage while still having the *-1 main
> package will save precious download time before being able to recompile an
> urgently needed package.

Slow network access is a moot point. A simple "yum update" will update all
available packages. And that includes the updated main package, not just
the -devel package.

Fedora Core and Extras depend quite heavily on online repository access,
so optimising dependencies for stone age network connectivity is
questionable.

Based on default update behaviour, it would (!) not matter whether the
dependency were on exact V-R or just V.

However, for an explicit action like "yum install foo-devel" (which is a
common thing for developers or users who build from tarballs often) or
"yum update foo" (your case), you really want that the user/developer gets
a matching pair of packages. Why?

Well, for the former (the yum install foo-devel case), especially package
release updates affect the main package often, so foo-devel ought to pull
in the corresponding main package, too.

What are the reasons for package release updates anyway?

Of course, patches. E.g. fixes for segfaults or other types of run-time
misbehaviour, which end up in the DSOs, but also in the -devel package
(static libs!). Rebuilds with a new compiler version (or e.g. PIC) may
alter the ABI, so installing the most recent foo-devel ought to pull in
the rebuilt main package.

Quite some package release updates affect the -devel package, e.g. static
archives (don't forget that the static archives would be built with
different patches than the DSOs), missing dependencies, broken pkgconfig
files and -config scripts, broken libtool archives, header fixes. The
updated spec changelog in the -devel package adds to the confusion if it
mentions fixed bugs, but the main package version is out-of-date (or vice
versa, the -devel package is old and confuses the developer). Your "poor
soul" example user apparently has an old -devel package installed, which
gets out-of-sync with the updated main package. Either he uses and needs
the -devel package, in which case he should update it anyway, or he
doesn't need it, in which case he can rpm --erase it to decrease update
download time.

Not forgetting packages where the major version is the least-significant
part of "Release" (e.g. snapshots, YYYYMMDD based versions). In such
packages, you can even discover API extensions, library configuration
and feature changes.

And of course, other packages in the repository are likely built against
the most recent -devel packages (its API, the constants and/or defaults
within the headers, possibly the output of included helper scripts).

Those are reasons why I advocate a tight relationship between -devel
package and main package. It's the road of least surprise. YMMV.