| Summary: | [patch] RESTRICT="noslotcache" for dynamic slots (mod_php, etc.) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | TGL <tom.gl> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | VERIFIED LATER | ||
| Severity: | enhancement | CC: | chutz+bugs.gentoo.org, flash3001, greg_g, nacka-gentoobugs, radek, sqlboy, vericgar, vhata-gentoo |
| Priority: | High | Keywords: | Inclusion |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 51411 | ||
| Bug Blocks: | 155723, 30166, 32177, 37721, 161388 | ||
| Attachments: |
nocache-restrict.patch
noslotcache-restrict.patch |
||
|
Description
TGL
2003-10-31 01:30:08 UTC
Created attachment 20002 [details, diff]
nocache-restrict.patch
The patch is against portage.py from 2.0.49-r15/16.
*** Bug 32712 has been marked as a duplicate of this bug. *** This can't be legitimately handled. The depend phase doesn't get any information that would enable it to change the values you're looking to "correct". You may fix this particular case, but the general problem associated with this still stands. Also this can cause a major speed impact. Now that I rethink of it, I'm no more 100% sure this was a good idea. The "issues" that false cache values produce are mainly cosmetics, and closing the few bugreports that result from it as invalid sounds okay to me, considering how sensible is aux_get. That said, I don't fully agree to your comments, so let's defend my (at least initial) point of view a last time: - on performance: I don't think this is such an issue. First, very few packages would be concerned by this flag. It is only $KV slotted drivers, apache modules and gcc. It is maybe 3 or 4 packages on an average system, and up to 10 if you real try hard to find them. For the others, since the flag is read from the cache, it doesn't change anything. Second, if in my previously submited patch I was regenerating values for each aux_get call, an obvious optimisation allow to do it only when SLOT is a requested value (let's call the flag "noslotcache" now). Sure, it is more restrictive, but SLOT seems in reality to be the only problematic dynamic variable (at least I've not seen bug reports about dynamic SRC_URI being wrong in cache). The point is that such requests on SLOT happen only: - once per package on a real emerge (for ~10 aux_get calls in total) - once per updated package on pretend mode (again on a total of ~10) - a few more times in --upgradeonly mode (because is_newer_ver_installed refer to slots in portdb... is this really correct btw?) And that's all that I've found, but I may not be exhaustive. Anyway, on a typical system for a typical emerge command, you should be able to count forced cache regeneration on your fingers. I will attach an updated patch that implement this solution. - on correctness: the environment during the pretend phase is not so bad. $KV is there (probably 95% of the dynamic slots), and shell code that is outside of the standard ebuild functions (like in apache mods ebuilds that call some "has_version" for apache, or gcc ebuilds that play with $CCHOST from env) also runs fine (in fact I've played to create SLOT using different other dynamic methods, and could not find anything that doesn't work). What exactly do you think may not work in the general case? That said, yes, there is a pathological case which is for instance "emerge -uv vanilla-sources alsa-driver": the kernel update may change what will become the slot for alsa, and you can't know it at depend time. But I don't think this would raise too much bug reports ; etcat did because it shows explicitly the slot, but it would not be affected by this flaw since it works on only one package at the time. Well, that's it, up to you to decide, will be fine for me in all cases. And sorry for the verbosity :) Created attachment 22030 [details, diff]
noslotcache-restrict.patch
Patch made against 2.0.49-r18.
*** Bug 30166 has been marked as a duplicate of this bug. *** Will have to stew on this one. I don't want this to be a popular attraction for a trivial fix. *** Bug 22579 has been marked as a duplicate of this bug. *** +1 for this from me (for mod_php mainly). Binary packages... You can't do this and have any kind of GRP work. Technically, it couldn't work now either because people do this and break things already. given some of the work in portage-ng so far, I remove my +1 for this. Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) Bah, this one you can even mark it WONTFIX or INVALID. It's old and there are probably better ways to fix that. Consider this closed as WONTFIX I'm not happy with current USE=multislot packages. A real solution for dynamic slots would really be nice... feel free to implement it ... the hack only exists because of portage's limitations All that's needed is an interface for the package manager to obtain the dynamic slots from the ebuild. Rather than pollute the existing constant metadata functionality, I think dynamic metadata should probably be accessed through a separate interface. For example, we could have RESTRICT="constant-metadata" that is available via the usual constant metadata interface ("depend" phase). That value of RESTRICT would indicate that a pkg_dynamic_metadata() phase needs to be executed using the local configuration. The dynamic metadata could override the constant metadata in cases where there are overlapping keys (such as SLOT).
(In reply to comment #17) > That value of RESTRICT would indicate that a pkg_dynamic_metadata() phase needs > to be executed using the local configuration. "local configuration" will likely be too vague. We'll probably need a way for the ebuild to specify exactly what environment variables the dynamic metadata will be a function of. |
