[sles-beta] php disappeared in beta6?

Joe Doupnik jrd at netlab1.net
Fri May 16 09:30:56 MDT 2014


     Yes, Wendy, correct. There are clever nuances one discovers in the 
source RPM build sequences which may help put together a nice local 
version of something. Beyond that we are on our own again.
     In a back channel discussion today the topic of licensing and 
support level came up for Modules, SDK and related items. It can be 
non-intuitive. Thus when matters mature another couple of steps it would 
be good to review those items with us as a sounding board for what might 
occur in the field after release.
     Speaking personally, I can imagine Matthias groaning about all of 
this, thinking "This is Not how we wanted to introduce the ideas." True 
enough, but then the general customer may have similar reactions at 
first. We do, however, thank you for your forbearance thoughout this 
discussion.
     Thanks,
     Joe D.

On 16/05/2014 16:19, Wendy Palm wrote:
> If we have to build something locally, we might as well download the latest version in public domain.
> There's no net benefit to pulling from SuSE and building ourselves.
>
>
>> -----Original Message-----
>> From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
>> bounces at lists.suse.com] On Behalf Of Beddingfield, Allen
>> Sent: Friday, May 16, 2014 10:09 AM
>> To: sles-beta at lists.suse.com
>> Subject: Re: [sles-beta] php disappeared in beta6?
>>
>> I agree with Simon here in being "concerned greatly".  While I can go out and
>> build this package or that package in OBS, why should I have to?  I think that
>> pushing anyone to use custom OBS packaging over what is included with the
>> OS is going to be very counter productive in the long run.  I'm assuming that
>> each of these "modules" will add an additional repository per-module?  If
>> these are available as channels in SUSE Manager and SMT (or whatever
>> replaces SMT), my technical needs will be met on this issue, and it will just be
>> an annoyance to me.  However, for those with other requirements, it can be
>> more of a problem.
>> I can foresee a number of situations where this is going to be problematic.
>> 1.  I occasionally get the request for someone who just wants to do a quick
>> test of something on a Linux system.  In that case, I just clone the VM (we
>> usually use VMware cloning to deploy VMs) from my template, and send
>> them the info.  I don't bother with registering with SMT, SUSE Manager, etc...
>> since they are just going to test something quickly and tell me to delete the
>> VM.  That is all fine now, with SLES 11, but with SLES 12, PHP won't be
>> available in this case, unless I register the VM, or register my template first,
>> install it, and then unregister before prepping it to be a template.  In that
>> situation, I would need multiple templates, since not every VM will need
>> every module.
>> 2.  As much as we may not like it, we still have the stubborn vendors out
>> there who will say "we support exactly this patch level, and nothing more",
>> and we have to firewall the hell out of the system to keep it secure.  Well,
>> currently if that vendor says they support SLES 11 SP2 or RHEL 6.3, etc... that
>> would mean that they support the exact patch level that shipped on the
>> media.  Well, with a repo, who determines what version they will support?
>> In reality, over here in the U.S. where we constantly have to justify why we
>> "can't just run Red Hat like everyone else and quit being difficult", they are
>> just going to drop SLES support.
>>
>> What is the answer?  I'm not sure...  we definitely need something better
>> than the current situation.  The php5* packages (being 5.2.x) and php53
>> (being 5.3.x) on SLES 11 is problematic.  First of all, I've already got people
>> wanting 5.5.x. Maybe a good compromise would be a snapshot at release
>> time of the modules all on the install DVD, and an update repo gets added on
>> registration?  Maybe a series of directories on the DVD that are added as
>> repos at install-time, if one selects the particular module?  That would seem
>> sensible to me.  It allows for offline installation from DVD, and continued
>> implementation of this new direction.
>>
>> There are many questions to be answered here by someone from SUSE:
>>
>> 1.  Can someone give us details of  how the module system is supposed to be
>> implemented?
>> 2.  How does one go about knowing what modules are available?
>> 3.  Will there be a php 5.5.x module, later one for 5.6.x, etc...  or will there be
>> one big repo with php55* and php56&* packages?
>> 4.  What other packages will be handled this way (python? ruby? tomcat?)
>> 5.  If this is to be implemented, what will be the release cycle/lifecycle?  Are
>> we going to get faster releases of php, etc...  via new repos or new packages
>> in a repo?  If so, that would be great for fending off our Ubuntu-loving web
>> developers.
>> 6.  Is it going to be considered some sort of license violation or violation of
>> terms of service if a person adds the "module", installs the RPMs, and then
>> removes the repo?
>> 7.  Is there some plan to completely modularize the distro, and have a
>> stripped-down OS install, and everything provided as a series of modules?  If
>> so, I personally think that would be horrible.
>> 8.  Why spring this on everyone now, at beta 6, with no announcement, and
>> it just gets discovered by a few of us in testing?  Was this planned all along, or
>> was it a last minute inclusion?
>>
>> Something else that should be addressed - I see as the next logical step, a
>> model where suddenly certain modules require additional entitlements...
>> Given that SLES has always been an OS where you pay one fee for all the
>> features, please don't go down that road...please!  Does anyone remember
>> having to pay extra per-CPU on RHEL to get XFS filesystem support?  Offering
>> of features a la carte gets complex, and has been a particular sore spot with
>> me when dealing with RHEL.
>>
>> Allen Beddingfield
>> Systems Engineer
>> The University of Alabama
>>
>> ________________________________________
>> From: sles-beta-bounces at lists.suse.com [sles-beta-
>> bounces at lists.suse.com] on behalf of Simon Flood
>> [S.M.Flood at ucs.cam.ac.uk]
>> Sent: Friday, May 16, 2014 8:11 AM
>> To: sles-beta at lists.suse.com
>> Subject: Re: [sles-beta] php disappeared in beta6?
>>
>> On 16/05/2014 12:43, Matthias G. Eckermann wrote:
>>
>>> I am afraid that you are contradicting yourself a bit:
>>> if you are able to use OBS, you _are_ online, and thus
>>> there is no reason to not use the Modules either from
>>> SCC or from an SMT or SUSE Manager (both with the
>>> appropriate repositories preloaded).
>> If that's the best response you (representing SUSE) can come up with
>> then that concerns me greatly.
>>
>> BTW I'm not the person who said they installed servers off-line - in an
>> earlier response to this thread I said "Whilst the servers I build do
>> have network access from the start (they PXE boot then install via
>> AutoYaST) they don't all register against NCC/SCC or even SMT."
>>
>> Simon
>> --
>> Simon Flood
>> Senior Systems Specialist
>> University of Cambridge
>> United Kingdom
>>
>> Novell/SUSE/NetIQ Knowledge Partner
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta



More information about the sles-beta mailing list