Re: Tag inheritance and "masked" newer builds
Am 19.01.2011 20:40, schrieb Alan Franzoni:
On Wed, Jan 19, 2011 at 5:46 PM, Oliver
Falk<oliver(a)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