Re: dependencies and applications

It seems to me that this is the best solution: PEAR 1.x (3 or 4, it should be soon IMO) the following happens: # pear install MDB This goes into the current MDB place aswell as MDB/1.0/ # pear install MDB2 This goes *only* into MDB/2.0/ This then has the following affects: Note that when I say current version I don't mean current at any given moment in time, I mean at this moment in time, so any package currently in PEAR being used. * BC is fully kept till we want to break it (this could even be left indefinately if you see fit pierre!) * Only one "extraneous" copy of the package need be kept (in that current version goes into current place and new place) * New scripts can start using MDB/1.0/ or MDB/2.0/ as appropriate * By adopting this as early as possible, we ensure the longest possible migration period * When we eventually move to PEAR 2.0 and break BC we can still do the E_USER_NOTICE as suggested * All this can be achieved in the package.xml... theres no need to work anything in to PEAR... check this out: For Current version we have: <filelist>

    <!-- For Current Directory Structure -->
    <dir name="/" baseinstalldir="PEAR">
        <file role="php">Info.php</file>
    </dir>
    <dir name="/tests">
        <file role="php">pear_info.php</file>
    </dir>
    <!-- New Directory Structure -->
    <dir name="/1.0">
        <file role="php">Info.php</file>
    </dir>
    <dir name="/1.0/tests">
        <file role="php">pear_info.php</file>
    </dir>

</filelist> For the new major version we have: <filelist>

    <!-- New Directory Structure *only* -->
    <dir name="/" baseinstalldir="PEAR/2.0">
        <file role="php">Info.php</file>
    </dir>
    <dir name="/tests">
        <file role="php">pear_info.php</file>
    </dir>

</filelist> Because we've been using MDB as the example in all this I think something has been overlooked, all packages in a given category will go into the same 1.0 and 2.0 folder, for example, PEAR_Info 2.0 and PEAR 2.0 will both be in PEAR/2.0/ - this means that we can even have PEAR 1.0 and 2.0 installed (what if you use PEAR_Info that was created before PEAR 2.0 then it might need some stuff in 1.0, this is something we *do* need. Think PEAR_Error also) Just tossing this into the air. This *really* seems like the least messy, easily implementable (its all on the individual package developers, and if they don't publish a new version of something by PEAR 2.0 perhaps it should be moved to siberia anyways), backwards and forwards compatible solution with the most amount of migration time. - Davey