Explicit requires vs. auto library requires, and fc3/devel versioning

[Ville Skyttä]

On Sun, 2005-03-20 at 07:34 -0800, Jeff Sheltren wrote:

> First, according to the old Fedora.us packaging documentation for using
> requires ( http://fedoraproject.org/wiki/HOWTOUseRequires ), it is enough to
> rely upon rpm to find the library required instead of listing a specific
> requires.  Is this still valid for packages in extras?

Yes, in the vast majority of cases the autogenerated library dependency
is correct and enough.

Strictly speaking, in some rare cases it's not enough if some other
_required_ changes which don't affect the .so name have been applied to
the required package.  In these cases, it is "correct" to put in a
versioned name/version/release based dependency.  In practice, this is
very rarely needed and even in those cases, most packagers tend to skip
adding the strict "name >= version-release" based dep anyway.  Leaving
it out is not _that_ big a deal, but doing so certainly isn't wrong.

>   In this case, I
> don't have a 'Requires: recode', but rpm picks up the dependency for
> librecode.so.0.  This works great for me (doing a yum install fortune-mod
> ends up grabbing recode as a dependency and everything gets installed
> happily), but is apt-get not able to follow dependencies in that manner?  If
> so, is it something we need to worry about?

apt-get will follow such deps just fine.  If some depsolver doesn't, the
depsolver needs to be fixed, not worked around in packages.

> Second, I'm a bit confused by Michael's comment:
> ----------
> But the fortune-mod packages released into Fedora Extras Development have
> the same version-release as those for Fedora Extras 3. That's a bug.
> ----------
> Which brings me to my question: how should releases differ between FC3 and
> development?  Are we supposed to have that FC3/FC4 tag as part of the
> release?  If so, is this *only* for the case where the FC3 version = FC4
> version?

Nobody knows yet.  At least for now, it's ok to use whatever you like,
as long as you're providing a working FC3->FC4 upgrade path and leaving
the possibility to provide new package releases for the older distro
open, again while still not interfering with the upgrade path.  This can
be trivially implemented eg. by adding a dot and a new ascending number
to the older distro version's package, for example:

  foo-1.0-1 imported to FC-3
  foo-1.0-2 imported to FC-4
  ...time passes, bugfix to FC-3 (only) is needed...
  foo-1.0-1.1 to FC-3, subsequent FC-3 releases would be 1.2, 1.3, ...
  ...etc...