Brendan Conoboy wrote: > Andy Green wrote: >> I would be the first to reach for a dirty but unanswerably effective >> hack to get me where I am going... But in this case I think the only >> true answer is to tag BuildRequires as being host or target in the spec >> file, not to unmanageably duplicate the target-world dependencies in the >> host. Eg >> >> HostBuildRequires: byacc (<-- for it is he) >> BuildRequires: libblah-devel >> >> ...where they are considered the same deal when hostArch == buildArch. > > Or TargetBuildRequires. Either way it's invasive and should be avoided > if it can be worked around. You really want the build system to do as > much as it can so you don't impact package maintainers unless absolutely > necessary. Yep, it is invasive but it is also defensible I think. It's the kind of thing that could be patched into the specfile at buildtime per-arch if that is what ends up happening. But here's an alternative Heuristic that isn't as reliable but might cope and has no specfile footprint 1) Package is called lib* or *-devel? goto 8 2) Check build host rpmdb 3) If present, check if any of the files in the package match /usr/lib/*.so or /usr/lib/*.a or /usr/include/*... if not, consider it present, else... 4) Check target arch rpmdb 5) If absent, goto 7 6) check if any of the files in the package match /usr/lib/*.so or /usr/lib/*.a or /usr/include/*... if so, consider it present, else... 7) error out with "package not installed on build host" (it didn't have a footprint in /usr/lib or /usr/include, take as a host utility) 8) Check target arch rpmdb 9) if absent, error out with "package not installed for $arch" 10) consider it present -Andy >> We can see if this logic raises objections anywhere given the effective >> forkage of rpm but I suspect it is a basic fact necessary for cross to >> work in rpm semantics. > > Forkage? There's rpm5.org and there's rpm.org trees now. If it was the plan to add a new spec keyword, one would want it to be globally accepted and not become one tree's special sauce. -Andy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
