After a few days now exploring whether I can install OpenStack on LEAP, I’ve encountered what I hoped should not exist… That a package might be available in both SLES and openSUSE 13.2 repos, but neither package would install on LEAP.
Now that I’ve encountered one example, it’s likely that there will be others as well and it’s anyone’s guess if it might be a common or rare occurrence.
euca2ools - It’s a package of command line tools from the Eucalyptus cloud project ported for use in OpenStack.
I’m not sure if there should be anything special with these tools, I recognize that there may be some issues working with a SLE core and openSUSE everything else but I would think these Cloud tools should implemented in the Application (not core), similar to what runs in kernel-space vs user-space.
So, it seems now short of submitting a request for build and waiting, my only option for now on LEAP would be to try to build from source.
Or, face the fact that I might have to just choose SLES or openSUSE instead of LEAP.
Package exists in the SLES 12 repository for SLES 12
Package exists in the openSUSE 13.2 repository for openSUSE 13.2
Package has not been built and does not exist in either SLES 12 or openSUSE 13.2 repositories.
Due to LEAP containing a SLES core but with all non-core openSUSE 13.2 functionality, it’s to be expected that apps from either SLES 12 or openSUSE 13.2 repositories should install on LEAP. Without knowing exactly where that line is drawn between “core” and “non-core” I’ve been assuming that any packages in a default LEAP is installed from the LEAP OSS with mostly core packages from SLES and might include some non-core packages from 13.2. If I want to install anything that’s not found in the LEAP OSS, I’m guessing that the app is “non-core” and I should lean towards installing from 13.2.
In any case, I assume that one of the three above scenarios should <always> work, and your example is one of the 3 scenarios (package from SLES installs on LEAP).
But, a 4th scenario has presented…
Package exists in both SLES 12 and openSUSE 13.2 repositories but neither will install on LEAP. Why this might happen, I have no idea based on my superficial guessing of the package apis. As I described, I believed that a package from one of the repos <should> have installed but this one (euca2ools) didn’t.
No, openSUSE packages for Leap come from Factory, not 13.2, SLE 12 came out before 13.2 and was split off before that. It can be hit and miss, but since the SLE version (12 SP1 beta, well rc1) in Leap is closer to SLE 12 than 13.2 I would expect more issues with 13.2 than SLE 12.
Maybe my error but my understanding is that Factory exists mainly to support the 13.2 roadmap, ie once Factory builds are deemed stable they are added to the 13.2 (or “Dev” successor today which means LEAP). This strongly suggests that a package API used in the roadmap and family of versions that includes 13.2 should include LEAP.
Is LEAP really closer to SLE 12 instead of openSUSE on non-core applications?
That would suggest that 13.2 apps could experience a high degree of issues ported to LEAP whereas if the API handled the new interfaces with the SLE based core, that would mean nearly automatic successful porting all of the 13.2 app inventory with minimal (more often than not zero) changes.
13.2 is a done deal, split from factory many moons ago. Versions don’t change (unless it’s a very good reason), else security/bug fixes are backported to 13.2 updates.
Later packages are built in the development projects which users can access if desired, but are not in the released version.
The SLE packages (because it it based around SLE 12 SP1) in Leap are/will change as it goes on towards the final release dates for both.
I guess it depends on what is considered ‘core’ applications, the way I understand it is;
Package ‘X’ version 3.0.0 Exists in SLE -> move to Leap with SUSE support/fixes etc.
Package ‘X’ version 3.1.1 Exists in Factory.
So, if maintainer or a user wants 3.1.1 in Leap, a submit request from factory to Leap occurs, Factory maintainer say yes to looking after it in Leap, so pushed it to Leap and maintain. Factory maintainer says no, leave it with SUSE folks. Package ‘X’ at ver 3.0.0 released with Leap until its either upgraded to 3.1.1 in the next release and maintained by the SUSE folks, or they may say, no we stay at 3.0.0 and move on. At that point the process repeats if a later package ‘X’ is in factory for the subsequent Leap release.
At the end of the day, if packages users are wanting in Leap aren’t in factory, they need to be submitted there, then can be submitted to Leap, if not they won’t be there in the upcoming Leap release.