[dev] Installation Thoughts

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Going through our installation process on a Debian VM  
>>> (specifically using a distro that has given us issues), and here's  
>>> what I think so far.  (This is simply on the PEAR install process  
>>> - this is independent of configuring/running any of our code.)
>>>
>>> * Two immediate fatal flaws I see.  beta/alpha packages are NEVER  
>>> installed and packages from foreign channels are NEVER installed.   
>>> At least with the default PEAR settings on Debian 7.
>>>
>>> I think we need to immediately change the installation command in  
>>> the docs to this:
>>>
>>> pear -d auto_discover=1 -d preferred_state=alpha install -a -B horde/horde
>>>
>>> Preferred state is irrelevant to an *installer* - it should only  
>>> matter to a *developer*.  Thus, if a developer has decided to use  
>>> the package, it should be installed no matter the state.
>>
>> Wrong, because it will also install alpha packages as soon as they  
>> exist, no matter what the developer suggested.
>
> This is true given my initial description.  What I was *trying* to  
> say is "installing alpha versions of software in the situation where  
> there are NO beta and/or stable versions available".  i.e. Gmail  
> being "beta" for like 10 years before it was declared "stable" -- at  
> some point during this "beta" process, it was the user's decision  
> whether they believed the product was stable enough to use, as  
> opposed to what the provider believed.
>
> That being said, I don't think there is a way to do this currently  
> via Pear CLI.

Correct, that's what I was trying to say.

> But there ARE packages that we use that are marked alpha that work  
> perfectly fine.  This is another situation where it is maybe  
> possible to use the PEAR libraries to determine these packages and  
> ONLY install these packages that are explicitly defined in, say, a  
> Horde package.xml regardless of the current stability state.

That would be great.

What already works with PEAR is to upgrade packages in the same state  
if the original state was lower than the preferred_state. But that  
doesn't help during the initial installation.

>>> And, for obvious reasons, we need to auto discover any additional  
>>> channels found during dependency processing.
>>
>> I've pondered suggesting to enable auto_discover too, but we don't  
>> have any required dependencies other than from pear yet, so this  
>> really hasn't been an issue so far.
>
> That's not correct.  Output from my previous e-mail:
>
> Attempting to discover channel "pear.phpunit.de"...
> downloading channel.xml ...
> Starting to download channel.xml (804 bytes)
> ......done: 804 bytes
> Auto-discovered channel "pear.phpunit.de", alias "phpunit", adding  
> to registry
> Attempting to discover channel "pear.nrk.io"...
> downloading channel.xml ...
> Starting to download channel.xml (778 bytes)
> .....done: 778 bytes
> Auto-discovered channel "pear.nrk.io", alias "nrk", adding to registry
> [...]
> Attempting to discover channel "pear.symfony.com"...
> downloading channel.xml ...
> Starting to download channel.xml (811 bytes)
> .....done: 811 bytes
> Auto-discovered channel "pear.symfony.com", alias "symfony2", adding  
> to registry

Yes, but that's all for Horde_Test, and like I said: not required.

>>> Takeaways from all this:
>>> 1. Not saying we should remove -B, but we have to workaround this.
>>> 2. Think our install documentation needs to be changed to require  
>>> '-f' for any PECL install.
>>
>> It's only required if you initially installed with -B
>
> But now you are requiring an admin to remember what they used for  
> the initial install.  All sorts of red lights/sirens when I see  
> something like this.  I should be able to run a command and it just  
> works.

He has to remember that anyway, e.g. if he installed into a separate  
PEAR. But as the many reports on the mailing list suggest, this is  
forgotten a lot. So making this easier makes a lot of sense.

> Because what people are going to do is go to the INSTALL page and  
> copy/paste.  In fact, that's EXACTLY what I did when I was going  
> through this exercise.  Like it or not, that's what people are going  
> to do.
>
>>> 3. I pick on horde_lz4 because, in my mind, it is pretty much a  
>>> REQUIREMENT.  Really.  The performance benefits
>>>    for the cost of installation are overwhelming.  So it pains me  
>>> to see that pretty much anyone installing
>>>    horde using the basic instructions is losing out on this (same  
>>> with the fallback - lzf).
>>
>> We may change the order so that the -a instructions come before the  
>> -a -B instructions.
>>
>>> * What would be nice is a way to script all this, to hide the  
>>> details from the user.  Even better, a script could then go and  
>>> query the installer whether they want to install/compile the  
>>> optional PECL packages and/or do some sanity checking.
>>>
>>> Seems to me like we could do something like with PHARs like the  
>>> composer script (getcomposer.org) that would handle all this for  
>>> us.  i.e.:
>>>
>>> $ curl -sS https://install.horde.org/ | php
>
> For the record, this won't work with a raw phar file.  Composer  
> actually is using a separate script to check dependencies and THEN  
> this script downloads the actual composer phar.  That's overkill for  
> us - we can do these checks in the phar file itself.  (Trying to do  
> this with a phar file will generate a PHP error).
>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]


-- 
Jan Schneider
The Horde Project
http://www.horde.org/