Warning - packages may not be available for LEAP

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.

This example:
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.


For sure there will be some (a lot even), depends if maintainers wish to stick with version/backports/fixes or keep moving with tumbleweed.

I’m sure the build target can be added if you as the project maintainers?

The surprising thing is that packages have been built for 13.2 and SLES.
You’d think that today packages built for one of those targets should work on LEAP but both do not.

Asking the maintainers to build helps out the next person who would otherwise encounter this package.

I wonder what the progress is on asking <all> existing 13.2 and/or SLES maintainers to build to a new LEAP target?


I have no issues with SLE 12 builds on Leap…

Did you see my post in the openSUSE News sub forum…?

Hmm … its difficult to tell which of those may be needed as a dependency. The package that I am pretty certain I would want is:

  • tesseract

I believe that is a requirement for gimage reader, and not having that for LEAP would possibly keep me on openSUSE-13.2.

Other packages that strike me may be needed by users are:

  • gstreamer-0_10-plugins-vaapi
  • gtkam
  • gtkpod
  • gtranslator
  • libzypp-tools
  • licq
  • linphone

The list linked from here https://forums.opensuse.org/showthread.php/509934-URGENT-ACTION-NEEDED-LAST-CHANCE-Make-sure-the-packages-youneed-are-in-openSUSE-Leap (which points to here: http://lists.opensuse.org/opensuse-factory/2015-09/msg00696.html) and in turn to here: http://paste.opensuse.org/28259518 is truly massive.

Your tesseract is there, renamed to tesseract-ocr so it doesn’t conflict with the game…

Packages aren’t disappearing, just not in the final release or dvd or ‘official’ repos. Development repos and such just need to add the build target.

After double checking, I see now that gtkam is also an application I use quite often for storing images from my digital camera.

I would be surprised if many other openSUSE users also do not do the same.

Actually thou, upon checking, I see I can also use digiKam which is possibly a better app.

I think I’m being misunderstood…

If a package is desired for a LEAP install,

There are 3 expected scenarios

  • 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.

Since it’s in factory, push to Leap as per the ML instructions and see if the maintainer will push to Leap for you;

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.