nia <nia%NetBSD.org@localhost> writes: > For reference, see the following bulk build where many packages > using librsvg fail in the depends stage: > > http://victory.netbsd.org/pkgsrc/packages/reports/HEAD/evbarm7-9.0/20201225.0632/meta/report.html > > Example: > > http://victory.netbsd.org/pkgsrc/packages/reports/HEAD/evbarm7-9.0/20201225.0632/mate-panel-1.24.1nb1/depends.log Is this a new problem, or do you think it's just newly noticed? I think we have to support people building from source on machines like a 1GB RAM RPI3, and so far I think that means not depending on rust, at least for now. Of course we also have to have good bulk build results. >> pkg_add: A different version of librsvg-2.40.21nb5 is already installed: librsvg-2.48.3nb3 > > What makes this bulk build interesting is that librsvg gets built BUT > librsvg-c is preferred, which forces an earlier version dependency: > > BUILDLINK_API_DEPENDS.librsvg+= librsvg<2.41 > > I'd guess that this is broken due to pkg_add always preferring to > install the newer version. Do you mean when pkg_add is invoked by the bulk build machinery to install the dependencies before building the depending package? Or is it that librsvg is a dependency of some other dependency, and that earlier dependency resolution picked the wrong one? In librsvg/buildlink3.mk, there is an upper constraint on API_DEPENDS but there isn't an upper constraint on ABI_DEPENDS: BUILDLINK_PKGSRCDIR.librsvg?= ../../graphics/librsvg-c BUILDLINK_API_DEPENDS.librsvg+= librsvg<2.41 BUILDLINK_ABI_DEPENDS.librsvg+= librsvg>=2.40.20nb4 So if that ABI_DEPENDS can have added < 2.41, or even if it's just replaced by that and we don't worry about old setups, I wonder if that works? > Should graphics/librsvg be explicitly skipped in bulk build setups > that prefer librsvg-c? Should the PKGBASE of librsvg-c be changed > so that it's not the same as librsvg? I see this as two sets of questions, one for the next few days, and one for the future, and am only going to think about Q4 this minute. Your two approaches both seem reasonable. With armv7 set up to prefer librsvg-c, I don't see much if any benefit to binary package users to have librsvg. I can also see having a different PKGBASE working fine. The other approach is to get the right package installed, mentioneed above. It may be that having two different versions of the the same PKGBASE is just asking for trouble. With ghostscript, same situation different reason, we have a metapackage and -gpl/-agpl. I am sympathetic to changing PKGBASE, but this feels like one package with two implementations instead of choosing a package, and I'm a tiny bit worried some bad thing we haven't thought of will happen I'd definitely like to hear from others, as usual.
Attachment:
signature.asc
Description: PGP signature