Mailinglist Archive: opensuse-buildservice (257 mails)

< Previous Next >
Re: [opensuse-buildservice] Trying to build helix-dbus-server
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Thu, 19 Oct 2006 16:25:27 +0200
  • Message-id: <200610191625.27849.adrian@xxxxxxx>
Am Thursday 19 October 2006 16:09 schrieb JP Rosevear:
> On Thu, 2006-10-19 at 15:50 +0200, Adrian Schröter wrote:
> > Am Thursday 19 October 2006 15:41 schrieb JP Rosevear:
> > > On Thu, 2006-10-19 at 15:39 +0200, Adrian Schröter wrote:
> > > > Am Thursday 19 October 2006 15:03 schrieb JP Rosevear:
> > > > > On Thu, 2006-10-19 at 10:38 +0200, Adrian Schröter wrote:
> > > > > > Am Wednesday 18 October 2006 19:27 schrieb Aaron Bockover:
> > > > > > > I'm slowly making progress in my quest to manage Banshee builds
> > > > > > > in the build service.
> > > > > > >
> > > > > > > helix-dbus-server is ... a DBus server that sits on top of
> > > > > > > Helix/RealPlayer and Banshee uses it as a backend for playing
> > > > > > > proprietary formats in SLED/SUSE (not openSUSE).
> > > > > > >
> > > > > > > The problem is that RealPlayer does not seem to be available
> > > > > > > under SLE_10.
> > > > > > >
> > > > > > > aaron@linux-0790:~/cvs/banshee/osc/Banshee/helix-dbus-server$
> > > > > > > osc build SLE_10 i586 helix-dbus-server.spec
> > > > > > > Getting buildinfo from server
> > > > > > > /tmp/buildinfo.QCMC6f.xml
> > > > > > > buildinfo is borken... it says:
> > > > > > > expansion error: nothing provides RealPlayer
> > > > > >
> > > > > > The SLE repo does only contain packages which are available for
> > > > > > SLES and SLED. We want to make sure that resulting package is
> > > > > > indeed installable by the users (because we want to keep the
> > > > > > common code base). packages, which are not available on both
> > > > > > products may go to the SDK, which means that the provider of
> > > > > > package which are build against need also to ship these.
> > > > >
> > > > > We ship realplayer on SLED.
> > > >
> > > > yes, but not on SLES. packages build against plain SLE do guarantee
> > > > to work on both products, so only the intersection of both are
> > > > available in this repository.
> > >
> > > Packages built against plain SLED are guaranteed to work on both
> > > products, otherwise whats the point of the common code base?
> >
> > This is not true, neither SLES nor SLED do provide all packages from each
> > other. There is no guarantee that all packages are available from the
> > other product. This is the reason why SLE_10 contains only the subset.
> >
> > A SLES customer has no way to get the realplayer package in an official
> > way for this example.
>
> The is a statement about support for customers, not about simply
> working.

I do not get you.

What I want to say is that a resulting package build against SLE_10 repo has
the guarantee that it is installable and it runs on all SLE_10 based
products. One package for all.

It can't run when a required package/lib/whatever is not available on all
products (which is the case for RealPlayer).

You need to clarify how a user can get the package and we can setup a special
target for this.

Yes, this is not nice, but this is not a problem of the setup of the build
service. It is the way the products got shipped.

> > The common code base does only say that there will be no incompatible
> > packages.
>
> This is not my understanding at all, all packages are built as part of
> one codebase and the different products (10.1, SLES, SLED) select a
> subset of that codebase for media and official support, but this subset
> is fluid until close to release and so we are basically guaranteeing
> things will work on any product.

And exactly this is not the case. We do have packages which are only available
on some of these products, but which might get required by some package.

If you want to be sure that a package, which requires RealPlayer should run on
all SLE products, you need to ship it for all products. But we don't do this
atm with a number of packages (RealPlayer is only one example).

> What does "incompatible" mean to you?

Packages which are on SLE_10 products are 100% compatible. The glibc on SLES
and SLED do provide the exact same set of symbols for example. There is no
symbol which is only available on one product.

> > > It seems odd not to be able to build packages in the build service for
> > > SLE that build perfectly fine in autobuild.
> >
> > autobuild contains always way more packages than they are on the
> > products. There is no guarantee that you can install a package without
> > dependency problems on a certain product just by building it within
> > autobuild.
>
> Yes, but we are talking strictly about packages that went out on the
> media in this case, which is only a subset of what's in autobuild.

But it went out only on one product, SLED. It did not went out on SLES.

> > The build service does guarantee this.
> >
> > So, it is not a bug in the build service, you need to change the products
> > in first place, so the content of the opensuse.org build service will
> > follow.
>
> I don't understand, change the products how?

As written before, when you want to be sure that RealPlayer based apps do work
always than the libs needs to be shipped for all products (it does not matter
if this happens via the media or via some online channel).

bye
adrian

--

Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian@xxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >