Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 32367 - [patch] RESTRICT="noslotcache" for dynamic slots (mod_php, etc.)
Summary: [patch] RESTRICT="noslotcache" for dynamic slots (mod_php, etc.)
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
Keywords: Inclusion
: 22579 30166 32712 (view as bug list)
Depends on: 51411
Blocks: 155723 30166 32177 37721 161388
  Show dependency tree
Reported: 2003-10-31 01:30 UTC by TGL
Modified: 2007-02-08 10:04 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---

nocache-restrict.patch (nocache-restrict.patch,803 bytes, patch)
2003-10-31 01:32 UTC, TGL
Details | Diff
noslotcache-restrict.patch (noslotcache-restrict.patch,842 bytes, patch)
2003-12-11 05:33 UTC, TGL
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description TGL 2003-10-31 01:30:08 UTC

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.

Reproducible: Always
Steps to Reproduce:
Comment 1 TGL 2003-10-31 01:32:00 UTC
Created attachment 20002 [details, diff]

The patch is against from 2.0.49-r15/16.
Comment 2 Marius Mauch (RETIRED) gentoo-dev 2003-11-04 12:22:08 UTC
*** Bug 32712 has been marked as a duplicate of this bug. ***
Comment 3 Nicholas Jones (RETIRED) gentoo-dev 2003-12-10 07:43:43 UTC
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.
Comment 4 TGL 2003-12-11 05:31:54 UTC
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 :) 
Comment 5 TGL 2003-12-11 05:33:48 UTC
Created attachment 22030 [details, diff]

Patch made against 2.0.49-r18.
Comment 6 Nicholas Jones (RETIRED) gentoo-dev 2003-12-23 21:55:54 UTC
*** Bug 30166 has been marked as a duplicate of this bug. ***
Comment 7 Nicholas Jones (RETIRED) gentoo-dev 2003-12-23 23:16:08 UTC
Will have to stew on this one. I don't want this to be
a popular attraction for a trivial fix.
Comment 8 Nicholas Jones (RETIRED) gentoo-dev 2003-12-28 22:15:16 UTC
*** Bug 22579 has been marked as a duplicate of this bug. ***
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2004-01-10 16:46:24 UTC
+1 for this from me (for mod_php mainly).
Comment 10 Nicholas Jones (RETIRED) gentoo-dev 2004-03-20 15:24:42 UTC
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.
Comment 11 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-02-14 04:58:39 UTC
given some of the work in portage-ng so far, I remove my +1 for this.
Comment 12 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:24:47 UTC
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. ;) 
Comment 13 TGL 2005-07-28 07:48:08 UTC
Bah, this one you can even mark it WONTFIX or INVALID. It's old and there are
probably better ways to fix that.
Comment 14 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 12:29:02 UTC
Consider this closed as WONTFIX
Comment 15 Zac Medico gentoo-dev 2007-01-11 19:11:35 UTC
I'm not happy with current USE=multislot packages.  A real solution for dynamic slots would really be nice...
Comment 16 SpanKY gentoo-dev 2007-01-12 15:56:03 UTC
feel free to implement it ... the hack only exists because of portage's limitations
Comment 17 Zac Medico gentoo-dev 2007-01-13 00:13:08 UTC
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).
Comment 18 Zac Medico gentoo-dev 2007-01-13 00:24:06 UTC
(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.