[opensuse-packaging] Converting factory devel packages to branch
Hi, I plan to mass convert all devel packages to branches if they are fall into one of the following categories: - they are a source link now - they contain the same sources as factory This will happen at the end of the week unless someone convinces me this a bad idea, so I would like to stress why I plan to do so: packages that have no relation to factory sources very easily divert as factory follows different white space indentation rules and it's near to impossible to check if a package has pending changes in the devel project or "just" whitespace differences. Source links break easily if you continue working in the devel project after the submit request - as such many projects prefer not to use source links. But branches do not have this problem, they even leave your white space alone - with branches the source server only touches the _link file and nothing else, so nothing can break your sources. That does not mean, there can't be conflicts in case someone pushes something to O:F that conflicts with your changes (which shouldn't happen in devel projects by policy). Converting the devel projects may break some scripts though as I'm pretty sure some rely on the existance of project.diff to see if there is a difference so my mail to talk about it. So what is a branch? It's a _link without diffs, the _link contains the revision of factory and additionally you have the full sources in the devel project. This means you can't easily find out from your osc checkout if the project made changes. Of course we can extend osc to store the md5 of the link target too, so you can adapt your scripts - but for now there is no such possibility from what I can see. Is that problem enough to outweight the advantages? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 19 of January 2010 10:45:42 Stephan Kulow wrote:
Hi,
I plan to mass convert all devel packages to branches if they are fall into one of the following categories: - they are a source link now - they contain the same sources as factory
Cool, some time ago I sent a list of devel packages aren't a link to factory [1]. I don't know how valid is it now, but I uploaded it to pack.suse.cz [2], so feel free to use it if you wish. [1] http://lists.opensuse.org/opensuse-factory/2009-10/msg00299.html [2] http://pack.suse.cz/mvyskocil/not_links.py Regards Michal Vyskocil
[snip]
Le mardi 19 janvier 2010, à 10:45 +0100, Stephan Kulow a écrit :
So what is a branch? It's a _link without diffs, the _link contains the revision of factory and additionally you have the full sources in the devel project. This means you can't easily find out from your osc checkout if the project made changes. Of course we can extend osc to store the md5 of the link target too, so you can adapt your scripts - but for now there is no such possibility from what I can see.
Is that problem enough to outweight the advantages?
I'll need to update some of my scripts, I guess, but that should be doable. Can someone confirm that if I submit something from a branch to oS:F and it gets accepted, even if some oS:F checkin scripts changes a bit the .spec file, the branch will be updated to be the exact same content as oS:F? For example, it'd be quite bad that the checkin scripts changing the License tags (from "GPL v2 or later" to "GPLv2+") create a difference between oS:F and the branch. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag 19 Januar 2010 schrieb Vincent Untz:
Can someone confirm that if I submit something from a branch to oS:F and it gets accepted, even if some oS:F checkin scripts changes a bit the .spec file, the branch will be updated to be the exact same content as oS:F?
For example, it'd be quite bad that the checkin scripts changing the License tags (from "GPL v2 or later" to "GPLv2+") create a difference between oS:F and the branch.
The checkin will not change the .spec file that is in the devel project. But normally you would work on the expanded sources (osc up -e) and those are always a "merge" between what changed in O:F and what changed in the devel project. As the license change happend in O:F only, the "merge" will make it appear to happened in the devel project too - and that's also what the devel projects will build. If you change the license tag too, you create a merge conflict (and this is about the only way to make a branch "broken"). To avoid this, you can use osc pull to pull the O:F changes explicitly into your project. Does this answer your question? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 19 janvier 2010, à 12:59 +0100, Stephan Kulow a écrit :
Am Dienstag 19 Januar 2010 schrieb Vincent Untz:
Can someone confirm that if I submit something from a branch to oS:F and it gets accepted, even if some oS:F checkin scripts changes a bit the .spec file, the branch will be updated to be the exact same content as oS:F?
For example, it'd be quite bad that the checkin scripts changing the License tags (from "GPL v2 or later" to "GPLv2+") create a difference between oS:F and the branch.
The checkin will not change the .spec file that is in the devel project.
But normally you would work on the expanded sources (osc up -e) and those are always a "merge" between what changed in O:F and what changed in the devel project. As the license change happend in O:F only, the "merge" will make it appear to happened in the devel project too - and that's also what the devel projects will build.
If you change the license tag too, you create a merge conflict (and this is about the only way to make a branch "broken"). To avoid this, you can use osc pull to pull the O:F changes explicitly into your project.
So it leads me to a few other questions/comments: + is there an easy way to know that there's something to pull? + the license example is something that should be auto-pulled, IMHO. I don't want to learn about the change in the parent package only when I change from GPLv2 to GPLv3... (or we should start killing the checkin scripts). [I understand it's probably not easily doable, but that's something we'll have to consider at some point] + would it make sense to have an autopull setting? That would mean "every time something changes in the parent package, pull if this doesn't break the branch package". Or is there already such a setting? I would guess that what most people would want to have is branch packages with autopull, and a big warning in the status page when a pull would break the package (which means someone has to manually fix the package). At least, that's what I would like to have, I think. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 19 janvier 2010, à 13:46 +0100, Vincent Untz a écrit :
So it leads me to a few other questions/comments:
+ is there an easy way to know that there's something to pull?
+ the license example is something that should be auto-pulled, IMHO. I don't want to learn about the change in the parent package only when I change from GPLv2 to GPLv3... (or we should start killing the checkin scripts). [I understand it's probably not easily doable, but that's something we'll have to consider at some point]
+ would it make sense to have an autopull setting? That would mean "every time something changes in the parent package, pull if this doesn't break the branch package". Or is there already such a setting?
I would guess that what most people would want to have is branch packages with autopull, and a big warning in the status page when a pull would break the package (which means someone has to manually fix the package). At least, that's what I would like to have, I think.
Note that I don't think it's a reason to block the conversion, btw. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Jan 19, 2010 at 01:46:26PM +0100, Vincent Untz wrote:
Le mardi 19 janvier 2010, à 12:59 +0100, Stephan Kulow a écrit :
If you change the license tag too, you create a merge conflict (and this is about the only way to make a branch "broken"). To avoid this, you can use osc pull to pull the O:F changes explicitly into your project.
So it leads me to a few other questions/comments:
+ is there an easy way to know that there's something to pull?
The "expanded" sources (i.e. the sources that you normally work with) are always "pulled". So "autopull" is true as default setting. You can change this vie the "linkcontrol" flag in that latest osc versions. If "linkcontrol" is set to true, you stay with the last committed version and need "osc pull" to update to the latest link target version. If "linkcontrol" is false you do not need "osc pull" at all. (The last sentence is actually a lie, latest osc versions will automatically switch to "linkcontrol true" for the local packae if the link is broken to give you an easy way to repair links.) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 19 janvier 2010, à 14:04 +0100, Michael Schroeder a écrit :
On Tue, Jan 19, 2010 at 01:46:26PM +0100, Vincent Untz wrote:
Le mardi 19 janvier 2010, à 12:59 +0100, Stephan Kulow a écrit :
If you change the license tag too, you create a merge conflict (and this is about the only way to make a branch "broken"). To avoid this, you can use osc pull to pull the O:F changes explicitly into your project.
So it leads me to a few other questions/comments:
+ is there an easy way to know that there's something to pull?
The "expanded" sources (i.e. the sources that you normally work with) are always "pulled". So "autopull" is true as default setting.
That's not what I mean: I want autopull on the server side, so that if gnome-panel in openSUSE:Factory is changed, then gnome-panel in GNOME:Factory will automatically pull the change (in the "non-expanded" sources, if that helps clarify). Why? Because it means I can change the license tag later on without a conflict with the license tag change that was done by the checkin script of openSUSE:Factory. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Vincent Untz wrote:
Why? Because it means I can change the license tag later on without a conflict with the license tag change that was done by the checkin script of openSUSE:Factory.
Why does the checkin to Factory modify the license tag anyways? Sounds like a job for rpmlint to reject invalid license tags. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 19 janvier 2010, à 15:28 +0100, Ludwig Nussel a écrit :
Vincent Untz wrote:
Why? Because it means I can change the license tag later on without a conflict with the license tag change that was done by the checkin script of openSUSE:Factory.
Why does the checkin to Factory modify the license tag anyways? Sounds like a job for rpmlint to reject invalid license tags.
Well, we apparently decided to move from "GPL v2 or later" to "GPLv2+", and other similar changes. And this is a good way to make the migration as painless as possible, I guess. (license tag was just an example; as long as checkin to factory changes the content of a package in some way, my point about autopull will stand ;-)) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 19. Januar 2010 12:53:59 schrieb Vincent Untz:
Le mardi 19 janvier 2010, à 10:45 +0100, Stephan Kulow a écrit :
So what is a branch? It's a _link without diffs, the _link contains the revision of factory and additionally you have the full sources in the devel project. This means you can't easily find out from your osc checkout if the project made changes. Of course we can extend osc to store the md5 of the link target too, so you can adapt your scripts - but for now there is no such possibility from what I can see.
Is that problem enough to outweight the advantages?
I'll need to update some of my scripts, I guess, but that should be doable.
Can someone confirm that if I submit something from a branch to oS:F and it gets accepted, even if some oS:F checkin scripts changes a bit the .spec file, the branch will be updated to be the exact same content as oS:F?
The files as stored in the source server are not touched. But by default an "osc checkout" or "osc update" is merging both versions (to have the same what the build workers are using. And we want it merged by default to see the effects of it immediatly). However, you can also decide to handle this manually. Please find more detailed informations on my blog posting: http://news.opensuse.org/2010/01/11/obs-supports-new-branch-and-merge-handli... bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag 19 Januar 2010 schrieb Stephan Kulow:
Hi,
I plan to mass convert all devel packages to branches if they are fall into one of the following categories: - they are a source link now - they contain the same sources as factory
I'm doing this right now. You've been warned :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (6)
-
Adrian Schröter -
Ludwig Nussel -
Michael Schroeder -
Michal Vyskocil -
Stephan Kulow -
Vincent Untz