When creating a stage1 using catalyst, the following error message is displayed. And it fails. emerge --quiet --usepkg --buildpkg --newuse --oneshot sys-apps/grep sys-freebsd/freebsd-libexec dev-libs/libiconv sys-devel/binutils sys-freebsd/freebsd-ubin app-shells/bash virtual/libc sys-devel/patch sys-devel/flex sys-apps/gawk sys-apps/sed dev-libs/openssl sys-devel/bison sys-apps/texinfo virtual/os-headers sys-apps/file app-arch/bzip2 virtual/package-manager net-misc/rsync app-arch/libarchive sys-devel/automake sys-apps/openrc virtual/editor sys-devel/make sys-freebsd/freebsd-contrib sys-freebsd/freebsd-usbin sys-apps/findutils app-editors/nano app-arch/gzip net-misc/wget sys-devel/libtool sys-freebsd/freebsd-sbin sys-freebsd/freebsd-mk-defs sys-apps/diffutils sys-freebsd/freebsd-lib sys-devel/gettext sys-apps/less sys-freebsd/freebsd-bin sys-apps/baselayout sys-devel/autoconf sys-devel/gnuconfig sys-devel/gcc !!! The ebuild selected to satisfy "dev-libs/libxml2" for /tmp/stage1root/ has unmet requirements. - dev-libs/libxml2-2.8.0-r4::gentoo USE="-debug -examples -icu -ipv6 -lzma -python -readline -static-libs -test" PYTHON_TARGETS="-python2_5 -python2_6 -python2_7" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( python_targets_python2_5 python_targets_python2_6 python_targets_python2_7 ) (dependency required by "sys-devel/gettext-0.18.1.1-r3" [ebuild]) (dependency required by "sys-devel/gettext" [argument]) !!! catalyst: run script failed. Reproducible: Always
Created attachment 332706 [details, diff] patch for profiles/default/bsd/fbsd/make.defaults Patch to add python_targets_python2_7 to BOOTSTRAP_USE
Wired. profiles/base/make.defaults has these lines. PYTHON_TARGETS="python2_7 python3_2" PYTHON_SINGLE_TARGET="python2_7" So it should be working without such modification.
(In reply to comment #2) > Wired. profiles/base/make.defaults has these lines. > > PYTHON_TARGETS="python2_7 python3_2" > PYTHON_SINGLE_TARGET="python2_7" > > So it should be working without such modification. catalyst ignores these specifications. When creating new stage1, USE="-*" is set. You can be reproduced easily. # USE="-* bindist build" emerge -pv dev-libs/libxml2 !!! The ebuild selected to satisfy "dev-libs/libxml2" has unmet requirements. - dev-libs/libxml2-2.8.0-r4::gentoo USE="-debug -examples -icu -ipv6 -lzma -python -readline -static-libs -test" PYTHON_TARGETS="-python2_5 -python2_6 -python2_7" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( python_targets_python2_5 python_targets_python2_6 python_targets_python2_7 ) FYI, http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=blob;f=targets/stage1/stage1-chroot.sh;h=e40982b95db348d49d053ca28a868b0727085ad5;hb=HEAD <snip> 51 # Now, we install our packages 52 [ -e /etc/portage/make.conf ] && \ 53 echo "USE=\"-* bindist build ${BOOTSTRAP_USE} ${clst_HOSTUSE}\"" \ 54 >> /etc/portage/make.conf <snip>
(In reply to comment #3) > (In reply to comment #2) > > Wired. profiles/base/make.defaults has these lines. > > > > PYTHON_TARGETS="python2_7 python3_2" > > PYTHON_SINGLE_TARGET="python2_7" > > > > So it should be working without such modification. > > catalyst ignores these specifications. > > When creating new stage1, USE="-*" is set. > You can be reproduced easily. Then this could happen on Linux too? @catalyst team & python team, could you take a look at on this problem?
We ran into this the other day on bug 447880. I still think we need to make the REQUIRED_USE constraint in python-r1.eclass optional.
(In reply to comment #5) > We ran into this the other day on bug 447880. > > I still think we need to make the REQUIRED_USE constraint in > python-r1.eclass optional. That would mean that a number of Python-using ebuilds will need to have something like REQUIRED_USE='python? ( ${PYTHON_REQ_USE} )'. As I see it, there's a significant space for failure here as that is rarely triggered but significant error, resulting in semi-random failures. I'd rather see stage1 building fixed to have the relevant implementations set even if the Python bindings won't be used.
(In reply to comment #6) I would rather export correct metadata -- there is no reason to enforce that constraint if there is no python involvement. It would be better to have an error that can be corrected (missing that REQUIRED_USE setting) than the current state which cannot be corrected by the ebuild developer.
(In reply to comment #2) > Wired. profiles/base/make.defaults has these lines. > > PYTHON_TARGETS="python2_7 python3_2" > PYTHON_SINGLE_TARGET="python2_7" > > So it should be working without such modification. As Yuta SATOH stated, catalyst uses BOOTSTRAP_USE for stage1 and sets USE="-*". (In reply to comment #5) > We ran into this the other day on bug 447880. > > I still think we need to make the REQUIRED_USE constraint in > python-r1.eclass optional. I need to run some tests for Michał, but I'd appreciate if the python team could avoid changes that make building stages hard, if not impossible. Any changes to system packages that affect USE flags need "careful" consideration as they're likely to break stage building.
Long story short: just set the damn variables to a reasonable value. There is no point in doing more work for a corner case. Let me restate a few points for ya: 1) USE='-*' is a *corner case*. It's not something users are really expected to do. If someone does such thing, he's on his own. He should be aware of the consequences and be ready to handle them rather than assuming everything should work out-of-the-box. 2) The REQUIRED_USE constraints work well for the *common cases*. They need to be satisfied to make sure that everything works correctly. And they are satisfied both in the default cases and every reasonable case set by user. 3) If you don't want Python installed, you should set USE=-python and avoid Python-dependent packages. If you really, really don't want Python, you should mask it. Emptying PYTHON_TARGETS or PYTHON_SINGLE_TARGET is not a solution for that. Exporting a better metadata is not necessary. It is not helpful either. That's just requesting more work from ebuild developers to make your corner case work as you expect it to, though *it gives no benefits*. If we had a way to visually 'disable' some of the USE flags based on the state of another one, that would be an interesting reason to export more detailed metadata. But there's no such thing, it's just a simple consistency check to avoid *broken* code paths. As an alternative, I could just remove the REQUIRED_USE and do the check in random functions exported by the eclass. But isn't that just a regression? The main reason for REQUIRED_USE was to get failures before the ebuilds start building, not in the middle of it. Therefore, this is even worse. So to sum it up, please set the damn flags already and fix your USE_BOOTSTRAP or whatever it is.
(In reply to comment #9) > 1) USE='-*' is a *corner case*. It's not something users are really expected > to do. If someone does such thing, he's on his own. He should be aware of > the consequences and be ready to handle them rather than assuming everything > should work out-of-the-box. It is a corner case that seems very easy to support here. > 2) The REQUIRED_USE constraints work well for the *common cases*. They need > to be satisfied to make sure that everything works correctly. And they are > satisfied both in the default cases and every reasonable case set by user. The common case also works without any REQUIRED_USE at all. > As an alternative, I could just remove the REQUIRED_USE and do the check in > random functions exported by the eclass. But isn't that just a regression? > The main reason for REQUIRED_USE was to get failures before the ebuilds > start building, not in the middle of it. Therefore, this is even worse. This honestly sounds like a better solution to me than an incorrect REQUIRED_USE constraint. Especially since the message produced by the REQUIRED_USE check sucks and users don't comprehend it [1]. [1] http://forums.gentoo.org/viewtopic-t-947176.html
I've replaced the REQUIRED_USE variables with manual checks as proposed. EOT.
*** Bug 447880 has been marked as a duplicate of this bug. ***
