Description: ------------ Bonjour ! # pear -V PEAR Version: 1.4.0a12 PHP Version: 4.3.10 Zend Engine Version: 1.3.0 Running on: Linux magister.toggg.net 2.6.10-1.770_FC2 #1 Sat Feb 26 21:40:22 EST 2005 i686 We want to split PEAR::Validate in one common and several smaller subpackages. e.g. some financial methods have been extracted from Validate and transfered in Validate_Finance. Start situation: Validate 0.4.1 alpha Want to install Validate_Finance-0.5.0 which depends on Validate-0.5.0 1) package_Finance.xml without dep: <deps> <dep type="php" rel="ge" version="4.1.0" /> </deps> ... # pear install package_Finance.xml ERROR: pear.php.net/Validate_Finance: conflicting files found: Validate/Finance.php (pear.php.net/validate) Validate/Finance/IBAN.php (pear.php.net/validate) Excellent ! pear tell us we did a bloody packaging ! 2) we put a "has" dep: <deps> <dep type="php" rel="ge" version="4.1.0" /> <dep type="pkg" rel="has" version="0.5.0">Validate</dep> </deps> # pear install package_Finance.xml Notice: Undefined variable: de in PEAR/PackageFile/v1.php on line 1105 ERROR: pear.php.net/Validate_Finance: conflicting files found: Validate/Finance.php (pear.php.net/validate) Validate/Finance/IBAN.php (pear.php.net/validate) Hmmm... 3) we put a "ge" dependency: <deps> <dep type="php" rel="ge" version="4.1.0" /> <dep type="pkg" rel="ge" version="0.5.0">Validate</dep> </deps> # pear install package_Finance.xml pear/Validate_Finance requires package "pear/Validate" (version >= 0.5.0), installed version is 0.4.1 Cannot install, dependencies failed install failed Ha ! That's the expected result ... Just, no more message telling we could use -a, --alldeps or -o, --onlyreqdeps ? So minor things, go ahead :) ! -- toggg aka crappy

Sorry, but your problem does not imply a bug in PEAR itself. For a list of more appropriate places to ask for help using PEAR, please visit http://pear.php.net/support/ as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PEAR. This is not a bug in PEAR. The problem is that you cannot use package.xml version 1.0 to split apart existing packages. You *must* use package.xml and use a <subpackage> dependency in the Validate package's package.xml. Fortunately, you can also continue to bundle Validate_Finance in the Validate package.xml version 1.0, and simply <ignore> all of the Validate_Finance files in the package.xml version 2.0. Words are not very helpful, I am happy to assist with this in private email :)

Greg we are not trying to force people to install everything when they install the main package. The new schema can't be that flawed that it needs to add some entries to the "main" package just so we can place a simple deps in the splitt of packages since we aren't seeking for anything else then placing a version dep from the splitt of packages (some of them) over the new slimmer "main" package

http://cvs.php.net/pear/Validate/package.xml?php=45536ecf0ad5bc5567d0a70f03939728 http://cvs.php.net/pear/Validate/package_Finance.xml?php=45536ecf0ad5bc5567d0a70f03939728

This is not a bug. Since you insist, let me explain. PEAR prevents you from overwriting existing files when you install a new package. Why? A malicious package could (for instance) include a slightly modified PEAR/Installer.php that would seem to perform normally and would instead do some nastiness. If the PEAR Installer did not raise a conflict between the two packages, then it would allow this overwrite to happen without a single warning. In addition, when upgrading packages, dependencies are *always* upgraded before the main package, to avoid breaking the new version of the main package if one of the dependencies fails to upgrade properly. Because of this, if the main package depends on a subpackage at all, the subpackage will be upgraded first. The file conflict test will always be performed against the files of the old package, because it is not possible to determine what will be installed with the new version of the old package without adding many more lines of code and LOTS more memory consumption. To get around this, the main package can specify the same kind of optional "has" dependency as it always has, but use a <subpackage> dependency to tell the installer that it is OK for the subpackage to conflict with the old version of the main package. It is still a "has" dependency. If you wish there to be no dependencies from the main package, that can work too, but you have to upgrade the main package first (order is important) $ pear upgrade Validate $ pear install Validate_Finance This way, there will be no conflicting files. Remember, optional dependencies are never installed by default. In addition, if you use optional dependency groups, they are not installed at all unless *explicitly* specified by the user. The --alldeps switch will not install them. In addition, the package.xml you have now will work if the user instead types: $ pear upgrade Validate_Finance as this will first upgrade Validate, and then install Validate_Finance. This is not a bug in PEAR

Greg, don't you get we're only talking of dep "has" vs. "ge" ?

Why should "ge" works and "has" not ? Anyway the error message proves that something is not working: Notice: Undefined variable: de in PEAR/PackageFile/v1.php on line 1105

yes, I did miss the actual problem in my reading through your notes. However, I'm going to bogusify this one once again for three reasons: 1) the bug of undefined variable $de is a typo but does not affect operation 2) rel="has" works fine 2) you should be using rel="eq" :) The problem is the error message telling you that version is ignored does not properly display. I will open a new bug for the notice. Also, a warning: make sure that if you use an rel="eq" dependency that it is possible to upgrade both Validate and Validate_Finance to the next version before you release, I'm not sure this has ever been attempted outside of unit testing. In other words, make sure that once you have Validate 0.5.1 and Validate_Finance 0.4.0 installed that you can upgrade Validate_Finance to 0.4.1 and Validate to 0.5.2 or something like that.

Sure Greg ! Actually we decided to use "ge" as we need main package and subpackages to evoluate independantly. A "eq" dependancy would necessitate to allways silmultaneously upgrade, what we don't want.