currently the -B flag requires all deps to be installed. it would be nice if the -B could make binary packages of all deps that are not installed along with the package that is being installed. the below shows that the -B flag won't work even if the package is the only package to be installed. <code> root@coffee mark # emerge -up openssl These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] dev-libs/openssl-0.9.7c-r1 [0.9.6k] root@coffee mark # emerge -uB openssl Calculating dependencies ...done! !!! --buildpkgonly requires all dependencies to be merged. !!! Cannot merge requested packages. Merge deps and try again. </code> my reasons for this are that i have cron running emerge sync daily and it also gets the latest source that's available. i'd also like it to build binary packages of all the updates that i can install later. i do not want to automatically install the packages because it would be harder to tell what point in time i have to go back to if a problem arises. Reproducible: Always Steps to Reproduce: 1. 2. 3.
oh yeah, this is similar to bug 14832, but i don't think that one really resolved anything. the emerge -eB world or emerge -eB package name doesn't help me either. no binary packages are built unless i use the -b. and again i don't want to install the package when i build the binary.
ok, i tried w/o the u and it works for one package (openssl build the latest binary w/o installing it), but i'd like to be able to do something like emerge -ueB world and have it build all binary packages w/o installing them.
what you're asking for is impossible what can be fixed is the fact that portage incorrectly detects that all dependencies arent met ... i see it all the time on my boxes when updating with -K
i don't understand you say this is impossible? i realize that if package A depends on package B library/headers or somesuch, then those must be "around" to build package A and would probably have to be installed at the same time as package A. it's a simple dependency concept. it would seem possible to build package B and add it to a temporary part of the environment. make a binary package of package B. next compile or whatever needs done to build the binary package of A. put both the binary packages in the binary package holding area (/usr/portage/packages?) and wait for the user to install them. also, wipe the temp area after being completed. it seems similar to what catalyst does, but that seems to need to build from the beginning each and every time. that's a lot of crunching. it might take my machines at least a week to build that scale of binary packages.
yes, but it's that 'temporary area' that wont work 100% of the time many packages make assumptions about includes, libraries, etc... that setting up a few environment variables to point to these 'temporary areas' wont fix
also, many packages (for example .la files) hardcode the full path to the library they linked against if the library was in a 'temporary area', that hardcode would be screwed up ... yes we could possibly fix .la files because they're plain text, but what about binary files ?
i don't know. it just seemed like a good idea to me to be able to build binary packages w/o having to install them right away. catalyst seems like a semi workable answer to this (is that what is intended to be used to provide the -g or -G switches to portage?). the problem with catalyst from what i can tell, is that it requires a complete system rebuild each time. i suppose even if this were done once a month a user would have _most_ packages available in binary format. i would say that it seems like a fairly big bug if software is compiled to binary that is hardwired to certain specific filesystem paths being in place. i'll set this bug to cantfix.
*** Bug 39024 has been marked as a duplicate of this bug. ***
