After emerge --sync today I got: # emerge -pvu --deep --newuse world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] app-doc/doxygen-1.4.3-r1 [1.4.3] +doc +qt +tetex 0 kB [ebuild N ] app-crypt/mhash-0.9.2 833 kB [ebuild N ] app-text/sablotron-1.0.1 -debug +doc -perl 474 kB [ebuild N ] app-doc/php-docs-200403 2,023 kB [ebuild UD] dev-php/php-4.3.11 [5.0.4] -X -berkdb +crypt +curl -debug +doc -fdftk -firebird -flash -freetds +gd -gd-external -gdbm +gmp -hardenedphp -imap -informix -ipv6 -java +jpeg -kerberos -ldap -mcal -memlimit -mssql +mysql +ncurses +nls -oci8 -odbc -pam -pdflib +png +postgres -qt +readline -snmp +spell +ssl +tiff +truetype +xml2 -yaz 3,918 kB [ebuild U ] app-text/acroread-7.0.0.2-r2 [7.0.0.2-r1] -ldap -mozilla 0 kB [ebuild U ] net-misc/rsync-2.6.5 [2.6.4] +acl -build -debug -ipv6 -static 628 kB # emerge -pv ">dev-php/php-4.3.99" These are the packages that I would merge, in order: Calculating dependencies !!! All ebuilds that could satisfy ">dev-php/php-4.3.99" have been masked. !!! One of the following masked packages is required to complete your request: - dev-php/php-5.0.4-r1 (masked by: package.mask) # Stuart Herbert <stuart@gentoo.org> (10 Jun 2005) # Masked until the eclass is finished, and the PECL packages are done For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. Why is PHP5 ebuild masked after being unmasked for long time? I have scripts that rely on PHP5 here. If for some reason php-5.0.4 do not work then why php-5.0.3 were removed? You can not mask all PHP5 ebuilds now... please! Reproducible: Always Steps to Reproduce: # emerge info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.12-rc6-ck2-gk1 i686) ================================================================= System uname: 2.6.12-rc6-ck2-gk1 i686 Unknown CPU Type Gentoo Base System version 1.6.12 dev-lang/python: 2.4.1 sys-apps/sandbox: 1.2.9 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16-r1 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.11-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -mtune=athlon-xp -Os -frename-registers -fweb -fforce-addr -momit-leaf-frame-pointer -funit-at-a-time -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -Os -frename-registers -fweb -fforce-addr -momit-leaf-frame-pointer -funit-at-a-time -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="pl_PL.UTF-8" LC_ALL="pl_PL.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,-z,now" LINGUAS="en pl" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 doc nls nptl pic linguas_en linguas_pl userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET
All the php5 packages are masked until we have everything ready in the Portage tree. There is nothing stopping you unmask them yourself by adding the appropriate entry to /etc/portage/package.unmask.
But by masking it you are breaking PHP for several hundreds people that _rely_ on PHP5 that they installed months ago and _it_ _is_ _working_. So why do you make portage downgrade it by default??? Why do not leave old ebuilds alone while making new versions? Or at least leaving stubs that will not allow installing but at least will not break existing users? I think something is seriously wrong here...
Hmm, I really hope there is _some_ concept now, at least. I can
Hmm, I really hope there is _some_ concept now, at least. I can´t see why this was first commited unmasked, then eclasses severely broken several times, then 5.0.4-r1 commited without package.mask and now after a few days everything gets hard-masked. My common sense dictates that something is not quite sane here. So now that Apache ebuilds are getting to some working shape we are breaking PHP instead? Hmmm. :/
From Gentoo Developer Handbook: ----------------------- bite here ------------------------------- 5.g. Removing ebuilds When removing an ebuild make sure that no dependencies in Portage are broken due to the removal - additionally, your CVS commit message should explain clearly why the ebuild is being removed from CVS. If you need to remove ebuilds, make sure you do not accidentally remove the newest/only stable ebuild for any architecture. If you would like to get a newer version marked stable, then please file a bug or ask on IRC. You should also not cause an unnecessary downgrade for any "~arch" when removing ebuilds - instead, it is best to get the newest version marked "~arch" first and then remove redundant versions of the ebuild. ----------------------- bite here ------------------------------- I think the last sentence above describes this case. I am reopening the bug since it is not resolved for me.
I don
I don´t want to fuel this fire but I saw two guys asking if you need help in Bug 95431 and the answers sounds like "no, thanks". I think you should think twice. Please, be more considerate of other people (read users) when making decisions about removing ebuilds from portage and hard-masking packages after they have been in ~arch for quite some time. Remember that the users are doing a lot of debugging/testing _for you_; and they need at least somewhat predictable state of things to be able to do that. Putting the whole PHP5 shebang into package.mask now makes zero sense to me, I'm really sorry to say.
Hardmasking is indeed not the problem here, you can use /etc/portage/package.unmask to unmask the package if you depend on it. The problem is the following: > If you need to remove ebuilds, make sure you do not accidentally remove the > newest/only stable ebuild for any architecture. If you would like to get a newer > version marked stable, then please file a bug or ask on IRC. Why is the php-5.0.3-r1 ebuild removed from portage?! All >=php-5.0.4 ebuilds are broken, so 5.0.3-r1 was the latest stable ebuild (in the ~arch tree). Is there a possibility to move that ebuild back into portage?
To add to my previous comment post, IMHO, if the php-5.0.3-r1 ebuild is not put back into portage,the php-5.0.4-r1 ebuild should be fixed.
How about now; need any help?
Hi, The PHP packages are masked because they are not ready to be in ~arch. This isn't a case of removing a package with an upgrade; this is a case of withdrawing a package because it's broken. If they work for you, that's great - unmask them and carry on using them. If you're not comfortable unmasking packages, please stop using non-stable packages. I suspect that you don't have a /usr/bin/php because your portage tree is not up to date, or you have a local copy of php5-sapi-r2.eclass in your overlay. Can you look at the top of /usr/portage/eclass/php5-sapi-r2.eclass, and copy the Header line in here please? If you have a copy of the eclass in your overlay, please remove it, and then try installing the package. Thanks, Stu
Hi. (In reply to comment #9) > The PHP packages are masked because they are not ready to be in ~arch. What packages? Does it include php-5.0.3 for example? > This > isn't a case of removing a package with an upgrade; this is a case of > withdrawing a package because it's broken. I can not test my installed php-5.0.4 currently because it is broken by downgrade of postgresql. So I do know if it is working or not. But I am more than sure that php-5.0.3 (or something like that) ebuilds were working for me (when they were the highest marked ~x86 in the tree) because I did win one cup using such php. So I still do not undestand why were they removed... > If they work for you, that's (they == excactly what?) > great - unmask them and carry on using them. If you're not comfortable > unmasking packages, please stop using non-stable packages. What are not stable packages? Packages marked as ~x86 are very stable (in 90% of cases). But I do not want currently to install new php (-5.0.4 or -5.1.0 or something). I just need working PHP5 (could be 5.0.3 or 5.0.2). And this bug is not about new packages being masked but old (5.0.3 for example) being removed with nothing (besides PHP4) left. I am (was - till downgrade of postgresql) perfectly happy with my php-5.0.3 (and maybe even with php-5.0.4 but I did not have time to test it). > I suspect that you don't have a /usr/bin/php because your portage tree is not > up to date, or you have a local copy of php5-sapi-r2.eclass in your overlay. What? # ls -al /usr/bin/php -rwxr-xr-x 1 root root 4277862 cze 10 12:17 /usr/bin/php My overlay is 100% empty. # ls -al /usr/local/portage/ razem 2 drwxr-xr-x 2 root root 1024 maj 21 22:49 . drwxr-xr-x 9 root root 1024 cze 2 18:52 .. My portage tree is very up to date. > Can you look at the top of /usr/portage/eclass/php5-sapi-r2.eclass, and copy > the Header line in here please? Here you are: # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/eclass/php5-sapi-r2.eclass,v 1.19 2005/06/12 18:33:57 stuart Exp $ > If you have a copy of the eclass in your overlay, please remove it, and then > try installing the package. Again: I do(/did) not want to install anything new if it is not ~x86. I just want(ed) to keep currently installed php-5.0.4 or if it is broken php-5.0.3 (it was certainly working for me for example 17 days ago, and after some time was replaced by php-5.0.4 that I did not test). That was in the bug. Now I am forced to (re)merge some php because postgresql broke it. And it must be PHP5 because all my scripts are for it. So I have some questions: 1. Was php-5.0.3 broken when you removed it from the tree? 2. Was php-5.0.4 broken when you masked it? 3. If 1. is false - could you restore php-5.0.3? 4. What is most stable PHP5 in the tree now? (In your opinion. As I am forced to merge something _now_...) 5. When will any PHP5 be set (at least) ~x86? Thanks.
IMHO, if the php5 packages were not ready for ~arch, then they should have never been added in the first place. Since they have been added, people using ~arch may become dependent on them! Retroactively ALL php5 packages are masked, which isn't that bad (you can manually unmask them). However, by removing the working ebuild (5.0.3-r1) from the portage tree, and leaving only non-working (after unmasking) 5.0.4 ebuilds in the tree is not such a good idea. I have synced the tree just now, and still, no php-5.0.3 in the tree! I can unmask >=dev-php/php-5, but the 5.0.4-r1 ebuild is broken (see previous posting) and so is the 5.1.0_beta ebuild. Please restore 5.0.3-r1; all people depending on php-5 will then have a working ebuild they can use by manually unmasking the php-5 series. Workaround: if you haven't unmerged you working php yet, unmask the php-5 series, and then copy your working ebuild version from php-5.0.x from /var/db/pkg/dev-php/php-5.0.x/ into /usr/portage/dev-php/php/ and emerge will stop whining about downgrading php.
Hi. (In reply to comment #11) I agree with you 100%. > Workaround: if you haven't unmerged you working php yet, unmask the php-5 > series, and then copy your working ebuild version from php-5.0.x from > /var/db/pkg/dev-php/php-5.0.x/ into /usr/portage/dev-php/php/ and emerge will > stop whining about downgrading php. But this will work only if the eclass was not changed too much? Also as I say I need to (re)emerge some php because of postgresql downgrade... Thanks.
Hi, The older php5 ebuilds are not going to be added back into the Portage tree. They were removed from the tree because they have been replaced by later versions - php-5.0.4 and php-5.1.0-beta. The php5 packages have been masked because we have discovered problems which we need to resolve. There is nothing stopping you from simply unmasking the packages and continuing to use them until we are ready to unmask them. Best regards, Stu
Hi, No offence but this is the most stupid bug closing explanation I had in my short life.. (In reply to comment #13) > The older php5 ebuilds are not going to be added back into the Portage tree. > They were removed from the tree because they have been replaced by later > versions - php-5.0.4 and php-5.1.0-beta. > > The php5 packages have been masked because we have discovered problems which > we need to resolve. There is nothing stopping you from simply unmasking the > packages and continuing to use them until we are ready to unmask them. You are saying: "We replaced working (at least partially working) PHP ebuilds with later not working, masked versions. You can rewrite all your (and your clients') scripts to use php4 or unmask new probably broken ebuilds - Gentoo is all about choice." Ok. I need nothing more. Happy breaking your users. Bye.
I'm sorry but I thought I was very clear in my previous posts and so are the other people complaining... But I'll insert another comment again: THE PHP-5.0.4 and PHp-5.1.0_beta EBUILDS ARE BROKEN! I would be happy to use the ebuilds in portage IF THEY WORK. But they don't. And the php-5.0.3-r1 build does. I'll repeat it for the very last time: there are currently NO working php-5 ebuilds in portage, the only working ones have been removed. IMHO this is a very bad, even if it is the ~arch tree. I wouldn't be complaining here if I could simply unmask the packages and be a happy user.
Man, this is hard. Still no explanation why taking out the working-for-many-people php-5.0.3 ebuild from portage; Still hard-masked php-5*; Two months, no fix, no apparent evolution. Sadly I can't unmask php-5.0.4 ebuild as it's reportly broken. Sadly there is no php-5.0.3 to unmask any more and it was working for me just fine. Right now Gentoo offer me two choices: 1. Keep using php4; 2. Hard unmask php5 which doesn't work so I go back using php4. I.e.,: 1. Use php4; 2. Use php4. Fine choices...
Apparently you do not know of http://svn.gnqs.org/projects/gentoo-php-overlay/. Please go there, read the information there, and test the packages provided there.
