[sles-beta] php disappeared in beta6?

[Joe Doupnik]

     If I might clarify procedures, it would go like this.
     Let us distinguish between tail and dog in this part of things. 
That means ship PHP and many other standard items as before, providing 
the long term base, and those are part of DVD1 when we build a server. 
No removed functionality at installation time. That's the pooch. 
Alternatives, which I am pleased to see, are options, "tail" items, 
which might require yet another set of channels or be on DVD1 in a 
useful manner. To be candid, the multiplicity of channels is getting out 
of hand, but I don't have a clever solution to cite here.
     The reason I chose those strong words is because they represent 
what we in the field would be faced with. One does not wish to think 
about what trade press articles would say, so we work out these things 
within our group.
     Thanks,
     Joe D.

On 15/05/2014 12:04, Olaf Kirch wrote:
> Hi Joe,
>
> On Thursday 15 May 2014 09:36:38 Joe Doupnik wrote:
>>       Without having heard Matthias' presentation on the topic, the
>> appearance at present is this is hostage taking. As we all know,
>>   PHP is a central component of building production servers. Chasing
>>   down -devel RPMs is awkward enough, now core material is being
>>   placed behind locked doors. Might someone offer a brief
>>   explanation of why this approach is being taken?
> "Hostage taking" and "locked door" are somewhat strong words... and I
> hope you'll come to a different conclusion once we're talking about
> the facts behind these changes.
>
> In a nutshell, SLES faces a dilemma with fast moving technologies.
> SLES releases are in the market for a very long time. Customers using
> SLES expect a high level of stability in everything, including APIs.
> Now, API stability is definitely not one of the focus areas of the
> people creating Web development frameworks. This includes php, ruby on
> rails, you name it.
>
> With SLES, we could definitely take the approach of companies selling
> pharmaceuticals: "Bayer Froozle fights migraine, except when you do
> this or that or something else, and by the way if you're unlucky, it
> might make your hair fall out, cause your ears to grown like balloons
> and your nose to turn green, ..." Just like that, we could say "In
> SLES, we keep all APIs stable, except for <insert longish list>, and
> we provide full support for everything, except for <insert another
> list>."
>
> In some weird coordinate system, this might be considered customer
> friendly, but in most it's not.
>
> In the past, we have had a very hard time to upgrade components such
> as php. Not really for technical reasons, but because of such
> expectations on the life cycle. So what we are going to do is to
> create several modules (aka channels) which will be free of charge to
> SLE customers. These modules will hold collections of related
> packages, and communicate a clear life cycle and support statement for
> each module.
>
> You discovered the drawback of the module concept. It's easy to miss.
> On the other hand, you receive a strong benefit - which is a regular
> refresh of the code base for components such as php, which was not
> possible before.
>
> One of these modules will be targeted at Web Development, and contain
> PHP.
>
> Regards,
> Olaf