Today python was removed from the default-USE-Flags, many packages wanted to be rebuilt. Also boost(-build) were rebuilt with USE=-python. cave fix-linkage realised that there was something wrong with libboost_python, and started rebuilding paludis. Which failed in pkg-setup. So: Why are all those USE-Flags checked in pkg-setup, and not properly via USE-Dependencies? Portage itself makes use of USE-Deps, so why can't paludis? It would have errored out before rebuilding boost without python, now I again need to rebuild boost with python enabled. There are some more such checks in pkg-setup, not only boost[python]. Reproducible: Always
(In reply to comment #0) > So: Why are all those USE-Flags checked in pkg-setup, and not properly via > USE-Dependencies? Portage itself makes use of USE-Deps, so why can't paludis? I suspect this is for backward compatibility; USE-deps require EAPI >= 2.
> I suspect this is for backward compatibility; USE-deps require EAPI >= 2. This line is from sys-apps/portage-2.1.9.42: selinux? ( || ( >=sys-libs/libselinux-2.0.94[python] <sys-libs/libselinux-2.0.94 ) ) And all currently installable portage-versions have support for EAPI 2 (paludis-versions of course, too), so backwards compatibility could not really be an argument. And people waiting several months/years for the next update never were supported by gentoo.
If you want good ebuilds, use the overlay. We're sticking with EAPI 0 in gentoo-x86 until there's a decent enough EAPI available that we can get rid of the overlay.
*** Bug 423923 has been marked as a duplicate of this bug. ***
I'm resolving this as WONTFIX. Upstream requests that we stick with EAPI=0 so that's what we're sticking with.
(In reply to Jeff (JD) Horelick from comment #5) > I'm resolving this as WONTFIX. Upstream requests that we stick with EAPI=0 > so that's what we're sticking with. Upstream should finally learn that they are not supposed to decide on downstream decisions. And this one effectively means that the package is e.g. never going to support Python properly. Preventing progress and sticking with EAPI=0 is a death sentence, and you could just lastrite it already.
Get rid of every other built_with_use and vdb_path in the tree, and then it will be worth making the change. Until then there's no benefit to moving.
Fixed in 1.4.2.
Er, someone might want to take a closer look at that 1.4.2 ebuild... a) What's csep? b) Why have you gone back to 'python' instead of 'python-bindings'? Do you understand why we aren't using the 'python' flag to begin with? This *really* shouldn't be on by default. c) Why do you have comments talking about syntax when you removed syntax-related things from PDEPEND? d) Why are you hard-enabling prebuilt-documentation? This should usually be disabled.
(In reply to Ciaran McCreesh from comment #9) > Er, someone might want to take a closer look at that 1.4.2 ebuild... > > a) What's csep? Removed. > b) Why have you gone back to 'python' instead of 'python-bindings'? Do you > understand why we aren't using the 'python' flag to begin with? This > *really* shouldn't be on by default. I don't see any of the profiles enabling python by default. If you do mind using USE=python for what it is used for, describe the problem to the ml, get a consensus, prepare the plan and we will work on doing it. > c) Why do you have comments talking about syntax when you removed > syntax-related things from PDEPEND? Removed. > d) Why are you hard-enabling prebuilt-documentation? This should usually be > disabled. Why should people rebuild documentation at every build? To get a different date in the footer?
Also, please don't hijack bugs. If your comments and actions don't regard the immediate bug, please open a new bug report.
