httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: Fresh libapreq2 RPMS
Date Sat, 19 Jun 2004 01:26:44 GMT
Quoting Joe Schaefer <joe+gmane@sunstarsys.com>:

> Yup.  IMO it needs to go alongside apr-config.

I've already made the RPMS for 2.03_04 where I put apreq2-config in /usr/bin, by
directly installing it from the source directory into the $RPM_BUILD_ROOT. I
have done the same for the CVS version from a few days back. I still need to
release both. Should be all done in the next couple of days. I'll keep you
posted.

> Actually I'm now having second thoughts about the value of --package-name.
> The issue I was trying to think about is that folks packaging rpm's and
> deb's will naturally put the perl glue into a separate package from
> libapreq2/mod_apreq, which means users might eventually have separate
> versions for the C and Perl API installed.  Down the road we may want
> the perl glue to demand a minimum libapreq2/mod_apreq version, which may
> be less than the current package number.  We should be able to do that
> through apreq2-config.
>
> I thought --package-name might help users here, but I don't see that
> anymore.  --package-version and --library-version are all that's really
> needed.  --package-name and --package-title should probably go away soon.

No worries. I'll keep an eye on it. For now, it'll just report whatever vanilla
package-name it has (i.e. I won't be changing anything).

With RPMS (and I would guess with Debian too), you can demand that Perl stuff
matches the version of C stuff, so there won't be any confusion there. It is
also very simple to do using Require in the RPM spec file. I'm not sure what's
in the spec file now, but I'll have look.

--
Bojan

Mime
View raw message