[sles-beta] php disappeared in beta6?

[Joe Doupnik]

     I think we are going in smaller circles while trying to describe 
installation procedures.
     Yours, and many others without doubt, do patching/updates at 
installation time.
     Mine, and many others without doubt, delay such patching and 
updating until later, for a variety of good reasons.
     Licensing is presumed to be done properly. Registration is a 
optional separate step.

     DVDs are readily available at no cost, by downloading, at meetings, 
from friends, and so on. Usually that is one disc. Hmm, ought that hold 
the basic installation in reasonably complete form?

     Presuming a good network connection to the world, a set of 
credentials, and shrewd guesses about which repositories hold what 
should not be requirements, but the present scheme is making be so.
     Presuming that patches and updates are done during installation is 
a bad idea.
     Offering version alternatives is a very good idea, but first 
removing the starting point from the basic installation is a very bad idea.

     I hope that all here can clearly identify those 
presumptions/preconditions/changes being proposed by the new scheme.
     I do not consider them to be slight as they put up a significant 
barrier which must be worked around by more manual labour.

     SMT is a gem, very much appreciated.

     There, shorter text than usual. Perhaps this is a sign of progress, 
but then one might need a note from Mother and register with various 
news channels to be certain.
     Joe D.

On 18/05/2014 12:10, Lars Marowsky-Bree wrote:
> 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
>