On 02.05.2012 09:27, Mathias Homann wrote:

Hi,

now that building has started again, how about the discussion about link vs. aggregate starts again, too...

I'm looking at the status page, and I see that almost half of the page is full of kernels being built.

Why is that? Because people forked them.

As far as I can understand, there are two reasons for forking a package instead of aggregating it:

1. you are making changes to it 2. you made changes to a different package that is used during build

Am I right with that? I think so.

...and is there, by any chance, an automated process to change a _link into an _aggregate?

The question to me is: why would you aggregate a kernel? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 2012-05-02 09:27:47 (+0200), Mathias Homann wrote:

now that building has started again, how about the discussion about link vs. aggregate starts again, too... I'm looking at the status page, and I see that almost half of the page is full of kernels being built. Why is that? Because people forked them. As far as I can understand, there are two reasons for forking a package instead of aggregating it: 1. you are making changes to it 2. you made changes to a different package that is used during build Am I right with that?

Yes, but your wording above is a bit misleading ("because people forked them"): it is also frequently the case that you just want to build the same package, without any changes at all, but against different versions of dependencies. That is a situation that requires linking rather then aggregating (if you aggregate, you'd most likely end up with ABI incompatibilities at runtime). That's really the trouble with aggregating: you don't know whether it's safe or not, because it depends on the other packages in the same project. If someone adds e.g. a newer version of a library that is used to build the aggregated package in the same project, it suddenly has side effects at _runtime_, for the users (rather than at build time, if there are any API incompatibilities). The only chance of making it more robust and predictable would be to track hashes of information about the dependencies that were used to build the original package (the one you'd aggregate to) and let the build fail if those don't match in the package that has the _aggregate. But most probably not quite as simple as it sounds :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org