apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr-1-config on mixed 32/64bit build server
Date Wed, 08 Apr 2009 22:50:24 GMT
Daniel Pocock wrote:
> - depending upon how fussy the packaging system is, it may not be
> thrilled about one package overwriting another package's files - RHEL
> hasn't complained about this, but maybe future versions will be more
> attentive to such issues

They were plenty attentive; their apr-1-configure is identical for both
packages from the fedora 10 -devel packages.

Hint-hint ... use the source luke :)

You'll find they did something very fedora-specific.

> I'm not suggesting apr needs to implement something special for every
> weird setup.  Rather, it just needs a generalisation that can be applied
> in the most popular cases (probably RHEL and Debian). 

I don't solve problems for popular cases.  We solve for all cases, or
we solve for none.

> Some possible solutions that I haven't completely thought through:
> - make apr-X-config part of the noarch package (it is just a script
> anyway), and have a command line option for specifying architecture,
> e.g, on RHEL, I could do the following:

No need, if they are identical.

> - alternatively, have different versions of apr-X-config, e.g.
> apr-2-config-x86_64 or apr-2-config-64; the end user would need to make
> sure that they invoked the right one

-1.  Counterintuitive, not conforming to build semantics of other packages.
If we want apr-2-trueconfig launched from the apr-2-config symlink, that
would make sense, where apr-2-trueconfig exists in the build/ dir.

Their solution is very elegant, and wish it were offered for backport.
Check it out ;-)

View raw message