[dev] Installation Thoughts

[Ralf Lang]

On 31.10.2013 00:30, Michael M Slusarz wrote:
> 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.

You're right for the cases you mention, but it doesn't cover cases with
packaged php but pear horde (which seems to be what most pear horde
installations have when they ask for help on the list).

I agree on packaged-php-and-horde, if available.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.horde.org/archives/dev/attachments/20131104/7cbd2c13/attachment.bin>