Mailinglist Archive: opensuse-buildservice (354 mails)

< Previous Next >
Re: [opensuse-buildservice] openSUSE: build service - osc local build and linked packages
  • From: Martin Mohring <martin.mohring@xxxxxxxxx>
  • Date: Thu, 08 Feb 2007 19:20:50 +0100
  • Message-id: <45CB6A02.9050500@xxxxxxxxx>
Adrian Schröter wrote:
> Am Mittwoch 07 Februar 2007 22:03:03 schrieb Martin Mohring:
>> Hi,
>> when trying to build a checked out package with the osc local build on a
>> package that is
>> linked, I get an error. E.g.:
>> $ cd Base\:build/binutils
>> $ osc build standard i586 binutils.spec
>> Error: specfile 'binutils.spec' does not exist.
>> This is a bit disturbing and makes the osc client local build option a
>> bit useless
>> in the sense that you would like to use it to:
>> a) add features to packages
>> b) test changes locally
>> c) commit to repository when the changes work
>> Two options were considered (when consulting Dr. Peter Poeml):
>> a) solve this in the buildserver (recommendation by Peter)
>> b) solve this in the osc client (recommendation by mine)
> Right, we need a source merge functionality somewhere (in osc/web client, in
> the API or even the backend). This should merge automatically such linked
> packages and also apply possibly existing patches to it.
> On the other hand the same part shall also be able to create patches, for
> example when you want to edit a package where you do not have write access to
> or for creating your own fork.
> The open question is where we do this implement.
> 1) In the client: An advantage would be that the different clients can
> optimize it for their typical usecase.
> The disadvantage would be that each client needs to implement it.
> On the other hand all clients need anyway to get adapted for this
> functionality.
> 2) On the server side (does not matter for now if API or backend):
> The advantage would be that the merge/diff functionality needs only
> to get implemented in one place.
> The disadvantage would be that we need two different interface to handle
> either the link meta data or the merged sources.
> The client side approach is of course easier to implement, but the question is
> if we can't avoid multiple work with the server side approach.
Maybe my second point was not explicit enough, but I wanted to argue that:

- links have a local semantic if used with the local client osc (if the
linked package is also locally checked out and locally modified)
- links have a non local semantic if the link does not point to a
locally checked out package
- if you dont want to break the checkout/change/test/commit cycle, this
local semantics must be implemented.

Thats also what I wanted to demonstrate with the "Base:build/binutils"
What should we do?
>> E.g. the above command should have the same semantics like this:
>> $ cd Base:build/binutils
>> $ cat _link && echo
>> <link project='openSUSE:Factory' package='binutils'/>
>> Then "osc build standard i586 binutils.spec" works like:
>> $ ln -s ../../<project>/<package> .
>> $ osc build standard i586 binutils.spec
>> including the fact that local files have priority over linked files with
>> the same name.
>> Any comments on the issue? More and more packages contain now links,
>> there is now
>> a linkable base of the Factory Packages in openSUSE:Factory. Soon there
>> will be tagging,
>> so there will be massive use of links in the future.
>> So I would be happy if you could fix that.
> you are welcome to join the development, extending the api server with a merge
> functionality would be a great start ;)
I would like to start with osc build working with links by a fix in osc,
because I need it :-)

Cheers, Martin

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

< Previous Next >
Follow Ups