Here is a small patch that add a restrict flag, "nocache", which makes
portage (aux_get) ignore the cache entry of a package. It solves issues
for packages such as "mod_php", which uses a dynamic SLOT value (depends
on the apache version for mod_php). In such cases, aux_get was reporting
the SLOT value from the cache (the default from repository metadata for
most users), and hence the output of "emerge -p" or "etcat" was often
This should allow to fix bug #32177 and bug #30166 at least.
Steps to Reproduce:
Created attachment 20002 [details, diff]
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]
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.