[dev] Installation Thoughts

Jan Schneider jan at horde.org
Thu Oct 31 09:04:01 UTC 2013


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

> Quoting Ralf Lang <lang at b1-systems.de>:
>
>> On 18.10.2013 20:34, Michael M Slusarz wrote:
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Mathieu Parent <math.parent at gmail.com>:
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> 2013/10/17 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.)
>>>>>
>>>>> (with my Debian packager hat).
>>>>>
>>>>> Shouldn't the recommended way to install Horde on distributions be
>>>>> using the native package manager?
>>>>
>>>> At least for those distros that keep the horde packages up-to-date,
>>>> yes, probably. But that doesn't mean that we shouldn't make the pear
>>>> installation easier, even on package-supported distros.
>>>
>>> And from our perspective, we have no control what happens downstream.
>>> So we have to provide an installation path that is easy-to-use under the
>>> assumption that this is the only way people are going to install.
>>>
>>>>> For Debian jessie, this can be done with:
>>>>> apt-get install php-horde-webmail # for example
>>>>>
>>>>> Complete instructions (including Debian 7) are at:
>>>>> https://wiki.debian.org/Horde
>>>>>
>>>>> This provide better upgrade mechanism as well as proper dependency
>>>>> tracking (PEAR lacks in those both areas, and Composer is not really
>>>>> better).
>>>>
>>>> Agreed.
>>>
>>> Can't speak for Composer, since I don't have too much experience with
>>> it.  But putting together the proof of concept script last night in a
>>> few hours would never have happened without it.  I was stressing over
>>> how I was going to use PEAR to install the necessary Horde libs for the
>>> installer script in a temp directory to package via phar.  When I used
>>> composer instead, I had in running in probably 5 minutes.
>>>
>>>>>> * 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.
>>>>>
>>>>> This seems a reasonable default.
>>>>>
>>>>> [...]
>>>>>>
>>>>>> This can be fixed by doing a force install (-f).  But I have to
>>>>>> admit that,
>>>>>> as someone familiar with PEAR/PECL, this is not apparent to me at
>>>>>> all.  For
>>>>>> someone -- i.e. pretty much every one else -- they are going to
>>>>>> think that
>>>>>> horde_lz4 is properly installed on their system.
>>>>>
>>>>> Yes. PEAR is broken in handling PECL packages.
>>>>>
>>>>>> Takeaways from all this:
>>>>>> 1. Not saying we should remove -B, but we have to workaround this.
>>>>>
>>>>> Why don't you simply remove -B?
>>>>
>>>> Because it requires build permissions and environments and
>>>> dependencies like external libraries that cannot simply be pulled in.
>>>> Installing without -B is explicitly documented by the way.
>>>
>>> To me it's simply the fact that you are potentially building a whole
>>> mess of modules that a) you are never going to use or b) won't compile
>>> on your system, which I believe is Jan's concern.
>>>
>>> The issue is that certain PECL features - like horde_lz4 - are entirely
>>> self-contained, so there's no reason NOT to build them.
>>>
>>> Hiding the install process behind a script allows us to force install
>>> things like horde_lz4 without the confusion/complexity of trying to
>>> explain to a novice user in an INSTALL file why they should do it (and
>>> why they should do it for a small selection of packages, but not all
>>> packages).
>>>
>>
>> The assumption that a server designated to run php code has a full-blown
>> c build environment may be wrong, especially if the pecl module needs
>> external headers not shipped.
>
> I entirely disagree with this.  If you are installing Horde on a  
> server where you already had to build PHP, the C environment  
> necessarily exists.  So that's not an issue.
>
> A package-based installation will hopefully have Horde packages  
> already available, so the above installation tactic is irrelevant  
> since they will never use it.  So that's not an issue.
>
> If you happen to use the package-based installation without a C  
> environment - isn't the whole purpose of package-based installations  
> that it is simple to install something like the C environment with a  
> single command?  So I don't see that as an issue either.  The build  
> command will fail, but the error message can offer that it may have  
> failed because the C build environment doesn't exist.  That is not  
> out-of-line -- after all, Horde is designed to be installed by users  
> that have at least *some* semblance of system administration.  A  
> failed build on 10-20% of installations, with an explanation why, is  
> still a whole heck of a lot better than the current install situation.

I strongly disagree. Installation should succeed on 99% of all  
systems. Advanced features can and should be installed optionally, if  
the environment and knowledge exists.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/



More information about the dev mailing list