| Summary: | etcat -v is reporting wrong slot for mod_php with apache2 | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Håkan Wessberg <nacka-gentoobugs> |
| Component: | Unclassified | Assignee: | Alastair Tse (RETIRED) <liquidx> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | tom.gl |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 32367 | ||
| Bug Blocks: | |||
|
Description
Håkan Wessberg
2003-10-28 01:35:29 UTC
it is one of the problems with the mod_php ebuild setting SLOT="${APACHE_VER}".
etcat gets the data from portage and the metadata was generated with APACHE_VER
= 1. although for me it is a little difference because i'm not using the
metadata cache generated from the rsync server.
% etcat -v mod_php
[ Results for search key : mod_php ]
[ Applications found : 1 ]
* dev-php/mod_php :
[ ] dev-php/mod_php-4.3.2 (0)
[ ~ ] dev-php/mod_php-4.3.2-r1 (1)
[ ~ ] dev-php/mod_php-4.3.2-r2 (2)
[ ] dev-php/mod_php-4.3.2-r3 (2)
[ ] dev-php/mod_php-4.3.2-r4 (2)
[ ~ ] dev-php/mod_php-4.3.2-r5 (2)
[M ] dev-php/mod_php-4.3.3_rc3 (2)
[ ~ ] dev-php/mod_php-4.3.3 (2)
[ ] dev-php/mod_php-4.3.3-r1 (2)
[ ] dev-php/mod_php-4.3.3-r2 (2)
% for x in /var/cache/edb/dep/dev-php/mod_php-4.3.*; do echo "`basename $x`:
`cat $x | head -n 3 | tail -n 1`"; done
mod_php-4.3.2: 0
mod_php-4.3.2-r1: 1
mod_php-4.3.2-r2: 2
mod_php-4.3.2-r3: 2
mod_php-4.3.2-r4: 2
mod_php-4.3.2-r5: 2
mod_php-4.3.3: 2
mod_php-4.3.3-r1: 2
mod_php-4.3.3-r2: 2
mod_php-4.3.3_rc3: 2
don't know how to fix it really, or if it is a etcat problem or portage problem.
Another effect of this is that "emerge -p" shows some mod_php
updates as if they were some new install (I mean, some "install
in a new slot" in fact, which is also "N")... This is not very
surprising tho, it is the exact same kind of aux_get call.
Maybe there should have some kind of "nocache" restrict flag
in ebuilds that use dynamic values for this kind of metadata,
and aux_get would not try to read/write in cache for them.
That way, it would each time recompute an up-to-date value.
(Yes, it would slow down a few things, but there are very few
such ebuilds.)
Because up-to-date values are okay, it is really only a
problem of cache. For instance:
% etcat -v mod_php
[...]
[ ] dev-php/mod_php-4.3.3-r3 (1)
(slot is wrong)
% touch /usr/portage/dev-php/mod_php/mod_php-4.3.3-r3.ebuild
% etcat -v mod_php
[...]
[ ] dev-php/mod_php-4.3.3-r3 (2)
(slot is now right)
true, basically, dynamic slots will produce weird results, same as dynamic depends. it is something that is not fundamentally etcat's fault but the way we need to have dynamic slots. i can't really fix that behaviour unfortuantely. You will be able to fix this bug for real if portage patch from bug #32367 is accepted by portage team. In that case, you will only have to add RESTRICT="nocache" to mod_php ebuilds (and also to mod_scgi and mod_pcgi2 for the same reason). |
