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 ;-)
