[opensuse-buildservice] openSUSE: build service - osc local build and linked packages
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)
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.
Thanks, Martin
PS: This issue has been confimed already by "Dr. Peter Poeml"
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.
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 ;) bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Feb 08, 2007 at 07:20:50PM +0100, Martin Mohring wrote:
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 you're missing that links are not just a simple symbolic reference to another package, but can also come with modifiers that change or replace files. I don't know if it makes sense to duplicate all of this (pretty complex) code in the client. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Feb 08, 2007 at 09:33:37AM +0100, Adrian Schröter wrote:
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.
The Backend already supports this. Or I'm misunderstanding your requirement? Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Donnerstag 08 Februar 2007 20:09:33 schrieb Michael Schroeder:
On Thu, Feb 08, 2007 at 09:33:37AM +0100, Adrian Schröter wrote:
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.
The Backend already supports this. Or I'm misunderstanding your requirement?
k, but it is not accessible via the api.o.o and not supported in osc yet. If we add this support there, we should also support the regeneration of the patch link on commit time. Otherwise a linked package would always become a full copy on commit. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
Adrian Schröter -
Martin Mohring -
Michael Schroeder