Mailinglist Archive: opensuse-packaging (106 mails)

< Previous Next >
Re: [opensuse-packaging] SLE_12_SP1 repository in devel projects
On Dec 18, 2015, at 2:40 AM, Olaf Hering <olaf@xxxxxxxxx> wrote:

Is there a reason why various projects build for SP3 and SP4 instead of
just a generic "SLE_11" target? I think the service packs are compatible
when used as a build environment.
Backward compatible, not forward compatible, i.e. things built for SLES 11
should work w/o modification in all later service packs, but something built
against a particular SP may not necessarily work with earlier SPs. SP2 or SP3
bumped the major kernel version; another big change I can think of is PHP,
which was 5.2 in SLES 11; then SP2 added 5.3 alongside it, and SP3 dropped 5.2.

Unfortunately the way package naming was handled made using extensions from OBS
difficult — stuff targeting SLE_11{,SP1,SP2} used PHP 5.2 only, and usually
broke the build in SP3/SP4, since the php53-devel pkg didn’t provide
‘php5-devel’, which is what most extensions BuildRequire. I built a shim
package [1] so I could at least build extensions locally and submitted it to
OBS server:php:extensions repo [2] but got absolutely no response.

I’ve mostly moved on to SLES 12 with its newer PHP (thankfully named just
‘php5’ again) rather than trying to fight this battle, but I really hope they
don’t repeat this naming mess, but rather just replace the ‘php5’ packages with
new versions whenever the next update cycle of the SLE12 Web/Scripting module

In packman, devel:languages:ocaml and
Virtualization only the generic "SLE_11" and "SLE_12" targets exist for
that reason.

Since SUSE:SLE-12-SP1:Update already exists (not sure if its already
populated) I wonder if it makes sense to adjust just the paths in the
existing "SLE_12" repositories instead of creating a new "SLE_12_SP1"
repositories in the devel projects.
I think it makes more sense to automatically add repos for the latest SP, and
expire repos old SPs after they fall out of support. By targeting only the
latest SP, packages may not work for some users on previous SPs. Of course,
one those are no longer supported, users need to upgrade (hmm... looks like I
need to take my own advice and start rolling out SLES 12 SP1)!


< Previous Next >