Bug 375276

This is right, but the reason is that there is no public download repo for SLE products. This can be only fixed if we have a public download URL for SLE base products or at least the SDK.

Lets ask the responsible persons if that is doable ...

That would also be extremely useful from the point of view of getting any development done on SLED. Having to download 4GB of SDK isos for a single package, then having to download another 4GB to get the source code for that package is rather annoying. 

I've been having to download to a remote server with 100mbit internet connection and extracting individual packages manually. Not everyone has that luxury.

Hello,

we are currently re-evaluating our strategy here, but you
should not expect a change in the near future for SLE 10.

We do not see many complains by customers with respect
to that issue at all.

One question: why do you need the source code?
It is available in the ISOs, but in general customers
are not supposed to use it, as re-compiling
would lead to loss of certifications and support.

I am personally connected via (relatively) small-bandwidth
and don't see problems of downloading full ISOs.
Well, I see it as an advantage, as a local installation
server is always faster than wide are network connection.
And this is what we know our enterprise customers doing as well.

so long -
Matthias Eckermann / MgE, SLES PM

This is not about customer requirements but third party developer/software vendor requirements.

The build service makes it easy to package software so that it can be installed and used on SLE as well as openSUSE and other distributions. If packages are built against the full set of SLE packages, including the SDK, then they may depend on any packages in that set. However, there is no way to know whether the package manager on the target system has access to any or all of these packages. I suspect few have the SDK available. 

The build service generates instruction files called YMPs which tell the package manager where it can locate packages. For example http://software.opensuse.org/ymp/openSUSE:Tools/SLE_10/osc.ymp contains instructions as to where the package manager can locate the build service command line client and all its dependencies. It states that the SDK packages can be located at http://download.opensuse.org/repositories/SUSE:/SLE-10:/SDK/standard/. If the target system package manager does not already know where the SDK packages are located it will look in this location. However, this is not correct, there is in fact no public location with the SLE base or SDK packages, only the ISOs. This makes deployment of software more difficult.

If one of your goals is to increase the amount of third party software available for your platform then it makes sense not to put barriers in the way of third parties deploying software onto your platform.

My other point was that publicly accessible individual packages and source code would be more developer friendly. Using myself as an example, today I wanted to backport a programme to SLED10, which involved building and testing it on a SLED install. The steps to do this involved:

0) Download 5 installation cd isos @ ~700mb each.
1) Install system
2) Download SDK to obtain required packages for development environment (Subversion, yast-devtools, yast2-devel, automake, autoconf - a total of less than 10mb) 2.4gb ISO download
3) Discover a difference in the yast2-pkg-bindings api on SLED, obtain source code to investigate (285kb total) 4.4GB source iso download required.
5) Read sourcecode, create fix, build.
6) Test

This task only actually required about 800mb of downloaded data to complete. In fact it required me to download over 12 gigabytes. A process that wasted my time and bandwidth, discouraging me from building and testing for SLE in the future, and also wasted your money as you appear to be paying for Akamai CDN to back the ISO downloads.

I hope that helps you understand the two issues.

The short term fix for this particular bug is simply to remove the reference to the unavailable SDK packages from the buildservice generated YMPs. Ideally in the long term it would be nice if the SLE packages were available online, even if access is restricted to customers.

I added this concept to my requirement notes for SLE 11. I take your input under advisement, I need to review with engineering how to do this practically before I commit either way.

short-term, yes, removing the entry seems advisable.

closing as Feature, moving discussion to fate#303865.