On Thu, 20 Nov 2008 09:13:21 +0100, Adrian Schröter <adrian@suse.de> wrote:

...

If I use a recursive project reference, is OBS smart enough to break a loop, or will it explode?

Yes, it does break a loop. But it really hurts the scheduler and our logs. And it does make absolut no sence to have a setup like this. When you need anyway both repos, you can put them together in one project.

What I need is not so simple. As I posted earlier, I want to build a rollup release including all updates, plus my own package hacks, and I want to bootstrap the whole thing from source. Somewhere the docs say the current project is searched first. That may be true for dependencies, but through trial and error, I learned that's false for the package itself. When it's already built, and you manually trigger a rebuild, hoping to bootstrap it against itself, that does not work. OBS searches down the chain, and ignores the package in the current project. After trying different ideas, I can see OBS was not designed with the idea of easily building a rollup release. I'm still puzzled how OBS builds against new packages from :Update when there are no packages listed in the project, and the metadata shows nothing either. What's going on behind the scenes to make that work? And why can't the same magic merge source packages, to make a rollup release like I want to do? -- Webmail for Dialup Users http://www.isp2dial.com/freeaccounts.html -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 20 Nov 2008 09:42:15 +0100, Adrian Schröter <adrian@suse.de> wrote:

You need to classify such package as "Keep: $your_package_name" in the project configuration to get this.

OK, thanks for that hint.

...

After trying different ideas, I can see OBS was not designed with the idea of easily building a rollup release.

Hey, how do you think we are building our openSUSE releases inside of it ? ;)

Well, if you won't reveal the magic, please consider this: self custom --> self update --> self repo ----> :Update repo What that means is, my custom packages have highest priority, then updates, then the main repo. And I want to bootstrap updates against my custom packages. How do you propose I achieve this without using recursive project references? -- Webmail for Dialup Users http://www.isp2dial.com/freeaccounts.html -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 20 Nov 2008 11:23:45 +0100, Michael Schroeder <mls@suse.de> wrote:

...

Somewhere the docs say the current project is searched first. That may be true for dependencies, but through trial and error, I learned that's false for the package itself. When it's already built, and you manually trigger a rebuild, hoping to bootstrap it against itself, that does not work. OBS searches down the chain, and ignores the package in the current project.

That should work. In what project/package are you seeing this?

In a home:test project, which I already deleted. I tried to recreate similar conditions, but cannot reproduce the problem, so now it's just a bigfoot sighting. If I see it again, I'll take a picture. :-) -- Webmail for Dialup Users http://www.isp2dial.com/freeaccounts.html -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 20 Nov 2008 09:13:21 +0100, Adrian Schröter <adrian@suse.de> wrote:

...

If I use a recursive project reference, is OBS smart enough to break a loop, or will it explode?

Yes, it does break a loop. But it really hurts the scheduler and our logs. And it does make absolut no sence to have a setup like this.

...

self custom --> self update --> self repo ----> :Update repo

What that means is, my custom packages have highest priority, then updates, then the main repo. And I want to bootstrap updates against my custom packages.

How do you propose I achieve this without using recursive project references?

I think I have better idea now. self: hack --> self redo --> self self ------> repo "hack" is a subproject containing my custom packages. May as well call them hacks. "redo" is a subproject containing suse updates, which I import from source rpms and checkin to my project. I don't see any other way to publish them in a rollup release. "repo" is the non-update suse repo. Since I import updated packages into "redo," by referencing the non-update repo, I can avoid certain updates if I wish. Sometimes suse updates break things, reassurances to the contrary notwithstanding. In self, I will use _aggregate to link everything I want to publish, collecting packages from hack, redo, and repo. The result will be that everything builds first against the _aggregates in self, giving the desired bootstrap effect without recursive project references. After exploring different ideas for using OBS, this seems to be my best option. -- Webmail for Dialup Users http://www.isp2dial.com/freeaccounts.html -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 20 Nov 2008 20:15:25 +0000, John Kelly <jak@isp2dial.com> wrote:

I think I have better idea now.

self: hack --> self redo --> self

self ------> repo

"hack" is a subproject containing my custom packages. May as well call them hacks.

"redo" is a subproject containing suse updates, which I import from source rpms and checkin to my project. I don't see any other way to publish them in a rollup release.

"repo" is the non-update suse repo. Since I import updated packages into "redo," by referencing the non-update repo, I can avoid certain updates if I wish. Sometimes suse updates break things, reassurances to the contrary notwithstanding.

In self, I will use _aggregate to link everything I want to publish, collecting packages from hack, redo, and repo. The result will be that everything builds first against the _aggregates in self, giving the desired bootstrap effect without recursive project references.

When I started using this, I noticed a defect. Some redo packages will not be published, they're only needed for building other packages in redo. That means any packages built in hack will not see them, and wrongly build against old versions in repo. To solve that problem, I changed the hack reference from self to redo: self: hack --> redo redo --> self self ------> repo Though indirectly, hack still loops back to self, via redo. But that still leaves a question: what of build-only packages in hack; redo won't see them to bootstrap against them. Solving that problem in general seems to require a recursive or circular project reference. Ugh, there we go again ... However, since I won't hack a package without publishing it, I don't care. All my hacks will exist in the self aggregate list, where they will be found for bootstrap purposes, and thus I can avoid the sin of project recursion. Just FYI, in case anyone else uses these ideas in their own project. -- Webmail for Dialup Users http://www.isp2dial.com/freeaccounts.html -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org