This is a summary of a discussion had between ferringb and myself, March 11 2005, between 19h20 PST and 20h20 PST. It revolves around packages that perform additional checks for various reasons to see if they can compile given the current system state. All of the following already have hacks in their ebuilds to handle them, which leaves things just dieing during the compile. 1. Dealing with php[45], we support a number of USE flags that deal with applications that are NOT in the tree, and are very unlikely to ever be in the tree due to their nature. This subverts portage's [R]DEPEND checking, as there is no entry for them (due to the lack of ebuild). See confutils.eclass $CONFUTILS_MISSING_DEPS for a complete list of them. These are primarily propeirtary commercial database applications that are supported by PHP, and we users that do use them. The only original implementation alternative when originally writing the eclass was to put some ebuilds in the tree that must always be injected (eg they fail when tried manually), so that PHP can depend on them, but this still breaks an automated build if they get pulled in. 2. Again an example using PHP. If the user is using php4, and they want to build it with USE=java, then the following conditions apply: - A JDK must be selected with java-config, and not a JRE. - The Kaffe JDK does NOT work with PHP. - The JDK must be of version 1.4*. JDK-1.[235] are NOT supported, and cause compile failures. These are upstream problems, and upstream says they are not going to fix them, as the Java support is not in PHP5 at all. 3. Packages that are heavily dependant on contents of the kernel source: net-firewall/ipset is my current example. The functionality is present in iptables patch-o-matic, and has been in and out of several kernel patchsets to date (it was even in -mm for a while, but got dropped again). It's not yet in the vanilla sources, but it may be there in the next major version. The user-space application is very tightly bound against the kernel. 4. Mutually exclusive USE flags with no preference. PHP supports several mutually exclusive sets of USE flags. Some of them are not binary choice either, but instead pick only one of the available set. If several of them are set, the ebuild bails out on purpose, rather than trying to choose for the user. 5. Depend-time checking that some dependancy is built with a specific USE flag. Eg making sure c-client or uw-imap is built with USE=ssl.
I fail to see the actual point of this bug ... Most of these problems aren't related other than PHP being involved and at least 4) and 5) (and likely 2) already have their own bugs. The other two are clearly package bugs from my POV.
genone: ferringb asked me to document my discussion I had with him, as to things that can break a build, and we can't check for at dependancy calculation time presently. 1. could be consider a bug, but how else can we easily provide certain sets of functionality for users, dealing with packages that aren't in the tree at all (Oracle esp.). We just let them install it manually, and then set the related USE flag - but this breaks RDEPENDs. The notion of packages that purposefully fail doesn't break RDEPEND, but it does break an automated build if the packages get pulled in. 2. just depending on virtual/jdk doesn't gaurentee a compatible JDK is set with java-config, which is why we need a check in the ebuild, and then this causes a build to fail if things aren't right. 3. again, this is a case where the ebuild has to check the current system, to see if it can compile properly, and fail if not, this breaks automated builds again, but I don't see any way to work around it. #4 and #5 i'll leave since you say bugs already exist for those items.
Another one now, in net-nds/openldap-2.2.23-r1. If you try upgrade from openldap-2.1 to 2.2, without following the upgrade instructions, then it WILL corrupt your database. To work around this, pkg_setup detects if you are doing an upgrade from 2.1 to 2.2, and displays the upgrade instructions, then fails out. Again, if this happens N hours into a build process, it stops the automated build.
5 doesn't belong here.
*** This bug has been marked as a duplicate of 75936 ***
This is pkg_warn() or whatever it turns into being talked about on -dev@g.o. Something like this will come about eventually.
