rpms/git-core/devel .cvsignore, 1.10, 1.11 git-core.spec, 1.9, 1.10 sources, 1.10, 1.11

[Ralf Corsepius]

On Mon, 2005-10-31 at 14:35 -0500, Warren Togami wrote:
> Chris Wright wrote:
> > 
> > It builds fine, and has internal macros to handle zlib-devel < 1.2.
> > It's runtime that fails (apparently, I haven't recreated this myself,
> > it was reported by someone running older distro).  But git-core uses
> > zlib's *Bound functions which seem to have been introduced in the
> > .so w/out bumping any library version (between zlib 1.1 and zlib 1.2).
> > So RPM creates implicit requirement on libz.so.1, which is satisified on
> > machine that has either zlib 1.1 or zlib 1.2.  However will fail during
> > runtime with the former.  So it seems that zlib >= 1.2 is best way to
> > handle that.  What do you think?

So, the purpose of this requirement is to force users running zlib-1.1
to upgrade to zlib-1.2? If users are pulling zlib and git-core rpms from
the same site (FC rsp. FE), this should not be a issue. All versions of
zlib having ever been shipped with FC had been > 1.2.


Nevertheless, you still will want:
BuildRequires: zlib-devel >= 1.2

Then, the package won't build on distros with older zlibs and will
prevent those people building against insufficient libz's to trip over
this issue, later (linking should fail).

> Usually we advise against adding requirements like this, because it is 
> unsupported to run packages built on one distro on another.  However in 
> a few cases like this were the soname was not bumped, I suppose it is 
> fine.
Well, this "R: zlib >= 1.2" shouldn't do any harm ;)

>   Please leave a comment above it explaining why it is that way though.
If you want to keep it, yes, but I don't see much reason for keeping the
equation.

Ralf