https://bugzilla.novell.com/show_bug.cgi?id=375276
User benji@opensuse.org added comment
https://bugzilla.novell.com/show_bug.cgi?id=375276#c5
Benjamin Weber changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|benji@opensuse.org |
--- Comment #5 from Benjamin Weber 2008-03-31 12:38:31 MST ---
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.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.