| Summary: | optionally allow emerge --usepkg to pull in build time dependencies | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Sunny Sachanandani <sunnysachanandani> |
| Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | adsmith, jakub, kumba, m.debruijne, mihalw, sunnysachanandani |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | ACCEPT_DEPENDS= (solar/zmedico) | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 148870 | ||
| Bug Blocks: | 144480 | ||
| Attachments: |
Add option to emerge for factoring in all deps on binpkgs
add a --mindeps emerge option |
||
|
Description
Sunny Sachanandani
2006-05-05 08:43:10 UTC
Uhm, I don't see why do you want to install build-time deps that are not needed for binary packages... I want this feature because I use binary packages as a backup mechanism. In case my system goes haywire I would like to replicate it exactly the same way it was before using binary packages. SO it would be nice if we had an extra option to include build time dependencies also with --usepkg . This bug will probably be expaned to give users a bit more fine grain control of all 3 depend levels across the board. However 2.1 is in a feature freeze right now. So it's probably going to not be addressed for 2-4 weeks. (In reply to comment #3) > This bug will probably be expaned to give users a bit more fine grain control > of > all 3 depend levels across the board. > However 2.1 is in a feature freeze right now. So it's probably going to not be > addressed for 2-4 weeks. > Yes I beleive we need more fine tuned control and this is absolutely the right thing to do. This is especially useful if the RDEPEND of an ebuild is broken. In that case the user can override it to install whatever is in DEPEND (since $RDEPEND is always in DEPEND). This would be useful for badly written ebuilds within the portage tree as well as external ebuilds. I would like to have this feature, too. I have 2 machines which differ just a little bit. make.conf is the same, but they have different packages. I normally compile on the first with --buildpkg and use --usepkg on the second because I don't want to compile everythin 2 times. But I want every computer run on as own and be completely installed - with the RDEPENDS! P.S.: Is portage 2.1 coming soon? I'm waiting for it! :-) (In reply to comment #5) > compile on the first with --buildpkg and use --usepkg on the second because I > don't want to compile everythin 2 times. But I want every computer run on as > own and be completely installed - with the RDEPENDS! I build packages with my desktop system and share them with my laptop like that. My current (sub-optimal) approach is to parse the output of `emerge -puD world` on the secondary system and then use the package list to install all the pre-built binaries. > P.S.: Is portage 2.1 coming soon? I'm waiting for it! :-) 2.1_pre10-r5 is available in ~arch and it should be relatively safe to use from now on because we're only doing bug fixes on it so that it will be marked stable in time for the 2006.1 release. (In reply to comment #6) > (In reply to comment #5) > > compile on the first with --buildpkg and use --usepkg on the second because I > > don't want to compile everythin 2 times. But I want every computer run on as > > own and be completely installed - with the RDEPENDS! > > I build packages with my desktop system and share them with my laptop like > that. My current (sub-optimal) approach is to parse the output of `emerge -puD > world` on the secondary system and then use the package list to install all the > pre-built binaries. > > > P.S.: Is portage 2.1 coming soon? I'm waiting for it! :-) > > 2.1_pre10-r5 is available in ~arch and it should be relatively safe to use from > now on because we're only doing bug fixes on it so that it will be marked > stable in time for the 2006.1 release. > Yes I am aware of this suboptimal approach but this would add junk to my /var/lib/portage/world . I use a perl script for doing exactly this but this is cumbersome :( . A centralised feature built into portage would be nice! (In reply to comment #7) > Yes I am aware of this suboptimal approach but this would add junk to my > /var/lib/portage/world . Use --oneshot to prevent it from being added to world. btw.. I use -Ke system or -gKe system when taking advantage of PORTAGE_BINHOST= The fix for this bug will be related to bug 48195, since it's also desirable to control whether or not build time dependencies are considered for installed packages (vs. binary packages that aren't installed yet). Created attachment 91510 [details, diff]
Add option to emerge for factoring in all deps on binpkgs
This is my first stab at patching emerge, and it's not against the actual untarr'ed package, but against the two files while cwd == /usr (drafted it in a hurry, would like comments on anything missed before making a better version).
I think this feature should be controlled via a command line option, such as you've done with --alldeps. One thing to keep in mind is that this control over resolver behavior should include not one binary packages that are not installed, but also (effectively binary) packages that are already installed. For example, when the command `emerge -uD world`, the resolver currently considers build time dependencies of installed packages (even though it doesn't necessarily have to). So, any fix for this bug should consider installed packages (bug 48195 will be fixed soon) in addition to binary packages that aren't installed yet. (In reply to comment #11) > This is my first stab at patching emerge BTW, I've been doing some refactoring of emerge, so your patch won't apply against trunk (2.1.1_pre2-r7 is the current state). You can checkout the latest version here: svn+ssh://svn.gentoo.org/var/svnroot/portage/main/trunk/ I don't see any need to export ALLDEPS into the environment. This feature is strictly a dependency resolver parameter, and I'd rather not add any new global evironment variables unless absolutely necessary. Perhaps the --alldeps option should be inverted, so that the users has specify an option such as --minimal-deps in order to prune build time deps whenever possible. My reasoning for the inversion is that the merging of binary packages is currently a special case that is inconsistent with any other dependency calculation. In every other case, build time dependencies are always considered (this may be considered a side effect of bug 48195). The main cases that I am refering to are `emerge -uD world` and `emerge --depclean`. In both of these cases, build time dependencies are always considered for installed packages (even when they aren't strictly needed). In order to keep the behavior consistent in all cases, I propose a --minimal-deps option that causes build time dependencies to be ignored for both binary packages and installed packages. With this feature, it will be possible to use `emerge --depclean --minimal-deps` to remove all build time dependencies that aren't needed at run time. The behavior of `emerge --usepkg` will be different than before, but the old behavior will still be available via `emerge --usepkg --minimal-deps`. Created attachment 91538 [details, diff] add a --mindeps emerge option This patch adds a --mindeps emerge option like I've described in comment #13. I'll post this on the gentoo-portage-dev mailing list to see if people like it or not. I would rather we not change the default behavior and would prefer that we go more of the route of Kumbas patch here. In order to do this correctly, I believe that this must be implemented in the realm of package sets. *** Bug 112270 has been marked as a duplicate of this bug. *** This is fixed in 2.1.2_pre2 by the new --with-bdeps option from bug #148870. *** Bug 152084 has been marked as a duplicate of this bug. *** |
