Tag inheritance and "masked" newer builds

[Oliver Falk]

Am 19.01.2011 20:40, schrieb Alan Franzoni:
> On Wed, Jan 19, 2011 at 5:46 PM, Oliver Falk<oliver at linux-kernel.at>  wrote:
>> you don't want that. since parent will likely include older libs. eg.
>> you build foopkg in parent against libblah-1.0, while in child
>> libblah-2.0 exists. and foopkg from parent will - of course - then not
>> work in child, because it was built against libblah-1.0, that is not
>> available in child...
>
> Such responsibility is handled via the opportune rpm dependencies; it
> will be impossible to install my package.
>
> Also, even the current strategy allows such conflicts, e.g.
>
> barpkg-1.0 is tagged  "parent" and depends on foopkg-1.0 which is
> tagged "parent" as well.
> foopkg-2.0 exists in "child", but there's no barpkg build in child,
> but since inheritance exists it will be impossible to install
> barpkg-1.0 from the "child" repo even though the build exists.
>
> However, if I say "latest build" and tag child inherits from parent,
> I'd always think "the latest available build for such package, either
> in parent or in child".  Maybe it may not be the best thing to do in
> all cases, but I'd like to know if there's a way to change the default
> behaviour.

You are right. It will not be possible to install it. That's exactly the 
point. You will break your repo... Say you build glibc in f13, while in 
f14 there's already a new version. You will not be able to build 
anything any longer, since you will not be able to even install the 
buildroot... Got the point?

I don't know if there's any option to disable tis behaviour for 
particular packages, but for a full repo I consider this dangerous!

-of