Please, test and mark stable the following PEAR ebuilds:
add the following to the list
It looks like php-pear.eclass defines:
DEPEND="$DEPEND virtual/php dev-php/php"
Why would it depend on both virtual-php and dev-php/php?
Also, wouldn't it have made sense to actually resolve this bug before making the dev-lang/php stuff stable?
1. php-pear.eclass is the PEAR eclass for the old-style PHP packages. The new-style PHP packages use php-pear-r1.eclass.
2. How could packages (like dev-php*/PEAR-*) that depend on the new-style PHP packages be stabilized before the the new-style PHP packages were stabilized?
"Please, test and mark stable the following PEAR ebuilds:"
My point is, shouldn't they have been tested before dev-lang/php went stable, and marked stable in sync with dev-lang/php?
It makes upgrading to the new php stuff rather tricky as an emerge update is causing blocks if any of the PEAR packages are depended upon by something. It also makes scripting updates rather difficult as an emerge -NDuav world won't complete and one has to manually update packages until the blocks are taken care of.
The "test and mark stable" is directed at the architecture teams.
The packages have been tested by the PHP Herd and quite a few early adopters of the new-style PHP packages.
I'm just a little frustrated I guess.
I saw php-5 went stable. Read the documentation on upgrading php, unmerged all the php packages, upgraded php, then find out the fast majority of the php packages I need won't merge because of this problem. So i had to backtrack and and redo all of this.
*** Bug 119712 has been marked as a duplicate of this bug. ***
Stop this ranting on keywording bugs, please. It's causing just *tons* of bugspam for all concerned arches and serves no good purpose.
things such as this simply kill who wants to use gentoo for servers... in my opinion a gentoo stable portage tree is needeed, I hope glep 19 will be a reality soon...
(In reply to comment #9)
> things such as this simply kill who wants to use gentoo for servers... in my
> opinion a gentoo stable portage tree is needeed, I hope glep 19 will be a
> reality soon...
Which part of my previous comment have you missed? Go rant elsewhere, not on keywording bugs. Things like keywording bugs don't kill anything, don't clutter this with off-topic comments.
I've marked most packages stable on ppc64, but I couldn't mark this packages stable on ppc64, because they missed ~ppc64 due to *bad version bumping* (keyword was just dropped):
I'm unsure how to handle this. Should I wait another 4 weeks or bump directly to stable?
Please bump to stable directly. Thanks.
stable on ppc64
x86 done, readd us if we missed anything.
alpha, ia64: Please, keyword this ~arch and stabilize when you are ready. Thanks.
SPARC'd them all (I hope)
~ia64 keyworded all of it - keeping ia64 cc'ed so we don't forget to stable later.
Since alpha and ppc never started bug #119461, I amd removing bug #119737 from this list.
(In reply to comment #7)
> *** Bug 119712 has been marked as a duplicate of this bug. ***
I reported the 119712 bug. This is an update:
> Please, emerge dev-lang/php first or put dev-php/php and dev-php/mod_php into
> /etc/portage/package.mask and it should be OK then (issue with default
> virtuals, it seems). Dunno if horde works with php-5.0.5, you might want to
> emerge =dev-lang/php-4* instead.
I tried that and I was ultimately able to emerge all pieces without portage
complaining. Unfortunately, the installed combination does not lead to
working horde/imp/turba. The PEAR modules are now marked stable and so is
php 5 but neither the stable version of imp nor its ~x86 marked version seem
to work. I suppose php 5 was perhaps made stable without regard to these
php applications. I'll try to downgrade back to php 4 as my company server
cannot be down much longer. Thanks for trying to help.
(In reply to comment #20)
> I tried that and I was ultimately able to emerge all pieces without portage
> complaining. Unfortunately, the installed combination does not lead to
> working horde/imp/turba. The PEAR modules are now marked stable and so is
> php 5 but neither the stable version of imp nor its ~x86 marked version seem
> to work.
Completely unrelated to this bug, see Bug 120047 (and there's a couple of others). Your complaints need to be directed upstream, the horde code is broken. You can use 4.3.11 meanwhile, we won't be fixing horde. You can have both 4.3.11 and 5.0.5 installed at the same time - read out docs: http://www.gentoo.org/proj/en/php/php4-php5-configuration.xml
> Completely unrelated to this bug, see Bug 120047 (and there's a couple of
> others). Your complaints need to be directed upstream, the horde code is
> broken. You can use 4.3.11 meanwhile, we won't be fixing horde. You can have
> both 4.3.11 and 5.0.5 installed at the same time - read out docs:
You are right it's not entirely related but someone marked the original bug
as a duplicate this one.
I am happy to report that PHP 4.3.11 works with horde. Thanks for your advice.
PHP had to be emerged a few times because it complains about various USE variables in a one-by-one fashion. It may therefore be useful for others to list the combination that worked for me:
1. packages.keywords file:
2. packages.use file:
=dev-lang/php-4.3.11-r5 cli cgi apache2 ctype expat fastbuild force-cgi-redirect
ftp gd iconv memlimit mysql nls pcre pic posix session socket ssl tokenizer tru
etype xml xsl zlib pear dba imap -recode -mssql
3. package.mask file:
As for your suggestion that I should complain upstream about horde apps not
working, I very much disagree. If gentoo developers include a package and
mark it stable, sysadmins will expect it to work. More importantly,
routine "emerge -uD world" issued on the production server should definitely
not bring any of its services down! I don't think I'd be allowed to put
Gentoo on any other server if this assumption could not be safely made so
I hope your view is not a majority one among the Gentoo developers.
(In reply to comment #22)
Please, with sugar on top, don't clutter keywording bugs with irrelevant off-topic comments. Thanks.
hppa wants in. ;-)
All packages in the list that were hppa stable for dev-php/php should now be stable for dev-lang/php.
All packages in the list that were hppa unstable are left untouched for now.
Now I marked new (dev-lang/php) versions as ~hppa when older (dev-php/php) versions were marked ~hppa. Unstable and stable hppa upgraders should be ok now. Keeping the CC for stabilizing at a later date.
Add to the list:
Why? Those packages have been merged into the PEAR-PEAR package (to avoid file collisions, for instace).
These were not marked ~ppc yet, so I've marked them ~ppc and will keyword them stable when they've spent some time in ~ppc (unless you'd like them pushed to stable now):
The others are all marked ppc stable.
I marked the remaining ebuilds ppc stable. Closing since we're the last arch.