| Summary: | Emerging masked package by path causes 10 second delay | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David Held <andukar> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
This is on purpose - we *really* don't want people to use emerge /path/to/ebuild as it breaks things in subtle ways. If you really don't want to do something then don't let it be done. Remove the feature, don't make it annoying. What kind of subtle ways? Why can't emerging by path be made functionally equivalent to adding that package name to /etc/package/package.*? Why not provide a --nowait switch, for people who still use that feature but don't want to be needlessly frustrated? Good point. It would be pretty easy to have an autogenerated package.keywords / package.unmask file which is updated when you emerge by path. Not registering properly in world, handling dependencies in weird ways, .. Likely does weird stuff wrt. overlays as well. Ok, then if it's so evil why don't you just disable the feature? The 10 second delay is an annoyance, it doesn't stop people from doing it. I'm ok with the feature being removed, but making it annoying is just silly. Hi again, Bryan. I understand your point, but please understand mine. What if rm had a mandatory 10 second delay built in, because deleting files is potentially dangerous? I mean, sure it has a -i switch, but it also has a -f which makes it not ask you if you know what you are doing. Also, regarding not registering with the world being dangerous - what about --oneshot. Also^2, you never provided a reason why emerging by path cannot add the package to the world and/or /etc/package/package.*. Thanks. This is getting ridiculous. emerge /path/to/ebuild is evil and damages your system in subtle ways that I've already described. Why is it so hard to understand that we *really* want to make sure you know it's bad? Please open a new bug if you'd like to have emerge /path/to/ebuild completely removed. Removing the 10 second delay is just not going to happen. And your comparison with rm is wrong as well.. Point being that rm actually does what it's supposed to do while emerge /path/to/ebuild doesn't do what you expect it to. Closing bug as we're just running around in circles here. Wait a second here... your verdict here seems to be that emerge by path is evil and damages things. Fine. But there isn't always a 10 second delay from emerging by path. Only when you emerge by path *and* the package is masked does the delay occur. a) Personally I'd be all for removing it, however it has a *very few* legit uses. b) "The 10 second delay is an annoyance, it doesn't stop people from doing it." - Actually it does. c) "Also, regarding not registering with the world being dangerous - what about --oneshot." - Ehm, that's exactly the point of --oneshot. The issue is with /path/to/ebuild being handled different by default. d) One nice thing about /path/to/ebuild is that it sometimes grabs a different ebuild than the one you specified ;) e) "It would be pretty easy to have an autogenerated package.keywords / package.unmask file which is updated when you emerge by path." - emerge is not supposed to touch /etc/portage f) "Why not provide a --nowait switch, for people who still use that feature but don't want to be needlessly frustrated?" - Besides the point: This feature is designed to be frustrating (see b) g) "Only when you emerge by path *and* the package is masked does the delay occur." - Ok, that might be a bug. Jason? The general thing is this (mis-)feature is a extremely nasty hack that should have never been added and should be removed, however it has a very few legit applications. Emerging masked packages IS NOT one of those. Marius: The delay occuring only when a package is masked is by design. Also, if the package specified is not the package that portage wants to install, emerge will quit. Everybody else: As the initial statement by emerge says, the feature is broken. It's only still around because it is planned to be fixed one day. If you think being annoying is bad, look through other portage bugs and see how many of them are due to people forgetting things that they easily ignored. |
If you try to emerge a masked package by path, portage will wait 10 seconds before performing any action. *** You are emerging a masked package. It is MUCH better to use *** /etc/portage/package.* to accomplish this. See portage(5) man *** page for details. >>> Waiting 10 seconds before starting... >>> (Control-C to abort)... Continuing... in: 10 9 While printing a message saying that it is better to use /etc/portage/package.* is fine, there is no reason to annoy the users who choose not to by making them wait 10 seconds. Reproducible: Always Steps to Reproduce: 1. Emerge masked package by path (ie: emerge -p /usr/portage/app-portage/gentoolkit/gentoolkit-0.2.0_pre10-r1.ebuild) Actual Results: I am annoyed and have to wait 10 seconds. Expected Results: Perform the requested action without waiting 10 seconds.