[sles-beta] php disappeared in beta6?

[Lars Marowsky-Bree]

On 2014-05-17T09:40:34, Joe Doupnik <jrd at netlab1.net> wrote:

Dear Joe,

>     There are a variety of views on putting together servers. Yours of patch
> immediately is one. Mine is build, test, polish, from the distribution DVD
> without network access, and then consider patching. Add variations in
> between.
>     One asks what patching brings, whether security fixes or "improved"
> files, or what, and the answer is often all of this. Security we watch
> carefully, but the rest we keep at arm's length until we can deal with
> consequences.
>     Servers are not always built with nice Internet connectivity, nor with
> customer center credentials handy, not with a list of sundry patch channels
> before our eyes. Insert DVD1, build, look, often isolated from worldly
> contact at this stage.

I can empathize with this approach to a point. Yet, as you state, I'd
imagine that security patches would be deployed immediately. And if
certain changes are considered risky (I obviously would disagree, given
the quality of our development processes and QA ;-), one certainly
would want to deploy them early and test them at built time of a server,
right? Catch things early, and not in production?

And I'd assume that the probability of someone wanting/needing a
specific (non-security) fix to make their scenario work is greater than
zero too; if noone needed it, we'dn't have patched it. Hence, again, a
mechanism for deploying updates (at install time or later) must exist,
or the deployment process is broken.

> codes. Further, we (at least myself) do not fully trust those "improved"
> additions until shown otherwise, so no automatic additions of them to a
> system.

I didn't say anything about automatic updates. Just that *some* way of
applying post-GA/FCS packages to any meaningful server must exists, and
that this same mechanism can be used to include the additional module
packages.

>     The second point in the discussion was complexity from additional
> channels. Finding the right channels is not easy, and then we must enable
> access to them, and so on through a bunch of detailed data entry. The
> existing channels illustrate this point.

For installing a server that you don't want to register (which seems to
be the concern here), this isn't strictly necessary. Just grab the RPMs
and deploy. Sure, you need to identify the packages once, or at least
register one server for convenience - but "zypper in --download-only"
isn't really a huge effort?

I obviously trust that you would still have sufficient subscriptions for
all servers deployed ;-)

>     The third point is the initial build (DVD1) ought to be as complete as
> has been say SLES11. Provide the full release suite, not a hobbled one.

The initial build is, for all intents and purposes, not the single means
by which to deploy a production server within latest one to three months
after release. There'll always be at least one security bug in that
time frame. Realistically speaking, despite all the QA and effort we put
into development, and our esteemed beta testers, there are also going to
be additional important fixes people will want very quickly.

Hence, there *must* be a way to include post-initial-build packages in
your process, certainly?

And, uhm, not to put too fine a point to it, but where did you get DVD1
or a supposed DVD2? Did you, by chance, download it? ;-) So there must
be *some* system with network connectivity that you can access and
download packages too! ;-)

> Options, versions of this and that, can be on a second DVD, but spreading
> beyond that soon becomes impractical. If the size of Options is not large
> then put them on DVD1 as well.

I can see the desire for convenience here. I won't, can't, and do not
want to speak for PM, but perhaps this could be considered.

Yet again, the packages on DVD2 will be outdated very soon after the
initial build was shipped. It is my sincere hope that someone deploying,
say, PHP, has a process by which they can ship updates to their servers.

It is true that this new model emphasizes this and having a process that
is not just effective but reasonably efficient at distributing packages
will be a big boost. And clearly it'll work better for servers that do
have access to SCC or an internal SMT/Manager instance; just like for
deploying updates in general. But this is still a far cry from "hostage
taking."

SMT is even free of charge.

I agree this change comes late in the beta cycle. That is unfortunate
and I can understand that this may cause some irritation among our
testers, since this is something you legitimately would have wanted to
test early. I doubt anyone from SUSE would disagree with that. That was
not intentional.

But if you look beyond this temporary hurdle of a slight change (some
might call it improvement ;-) to your deployment and update processes,
what is your opinion on the basic idea behind modules and the value they
are supposed to provide? Additional supported updates and features for
the faster moving parts of the software eco system?

To me, that sounds like a very good thing.


Regards,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde