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"
example.
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