[dev] Installation Thoughts

Michael M Slusarz slusarz at horde.org
Fri Oct 18 21:22:03 UTC 2013


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.  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.

>> 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

>> 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.

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]



More information about the dev mailing list