FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Build System

 
 
LinkBack Thread Tools
 
Old 01-19-2011, 03:46 PM
Oliver Falk
 
Default Tag inheritance and "masked" newer builds

On 01/19/2011 05:34 PM, Alan Franzoni wrote:
> Hello,
> we've just found out a behaviour we'd like to change in koji.
>
> Simple case:
>
> two tags: child and parent, with child (obviously) inheriting from parent.
>
>
> builds:
> foopkg-1.0.0-1 is tagged 'child'
> foopkg-2.0.0-1 is tagged 'parent'
>
>
> If I list the builds in the 'child' tag, setting inherited and latest,
> i get foopkg-1.0.0-1 - it seems that koji resorts to inheritance only
> if a build for a package name does not exist in the required tag.
>
> Is there any way to prevent this from happening, and get the "truly
> latest" build for a package in the 'child' tag?

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...

you know what i mean?

or let me describe it differently: you don't want packages build in
parent tag to break you child tag...

-of
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 01-19-2011, 06:40 PM
Alan Franzoni
 
Default Tag inheritance and "masked" newer builds

On Wed, Jan 19, 2011 at 5:46 PM, Oliver Falk <oliver@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.

--
Alan Franzoni
--
contact me at public@[mysurname].eu
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 01-19-2011, 07:09 PM
Oliver Falk
 
Default 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@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
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 01-19-2011, 07:16 PM
Mike McLean
 
Default Tag inheritance and "masked" newer builds

On 01/19/2011 11:34 AM, Alan Franzoni wrote:
> Hello,
> we've just found out a behaviour we'd like to change in koji.
>
> Simple case:
>
> two tags: child and parent, with child (obviously) inheriting from parent.

This is the correct behavior. Furthermore you will note that the
'latest' build in a given tag is the one that was most recently tagged
there rather than the one with the greatest version-release.

Without this behavior, you would not be able to override builds further
down the inheritance, or within a tag.

> builds:
> foopkg-1.0.0-1 is tagged 'child'
> foopkg-2.0.0-1 is tagged 'parent'
>
>
> If I list the builds in the 'child' tag, setting inherited and latest,
> i get foopkg-1.0.0-1 - it seems that koji resorts to inheritance only
> if a build for a package name does not exist in the required tag.

While different folks use tags and inheritance differently, I would
generally consider such a situation to be incorrect tagging. Inheritance
is intended as a progression of sorts, so I don't think it makes sense
to tag an older build in a child tag unless you are deliberately overriding.

You might want to scan for such situations and correct them as need be.
I may have a script around here that does something like this.

> Is there any way to prevent this from happening, and get the "truly
> latest" build for a package in the 'child' tag?

No, and I don't see that changing.

What I can see is adding a policy check that could be used in the tag
policy to prevent such masking builds from being tagged (though of
course admins can override tag policy with --force).
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 01-19-2011, 07:29 PM
Alan Franzoni
 
Default Tag inheritance and "masked" newer builds

On Wed, Jan 19, 2011 at 9:16 PM, Mike McLean <mikem@redhat.com> wrote:

> Furthermore you will note that the
> 'latest' build in a given tag is the one that was most recently tagged
> there rather than the one with the greatest version-release.

Uhm, that's interesting and probably not what I would expect.

> While different folks use tags and inheritance differently, I would
> generally consider such a situation to be incorrect tagging. Inheritance
> is intended as a progression of sorts, so I don't think it makes sense
> to tag an older build in a child tag unless you are deliberately overriding.

Sure it is! The incorrect tagging happened just because I made wrong
assumptions. Now that I know how it works I'll just prevent it from
happening.

> What I can see is adding a policy check that could be used in the tag
> policy to prevent such masking builds from being tagged (though of
> course admins can override tag policy with --force).

This is what I was thinking to do.


--
Alan Franzoni
--
contact me at public@[mysurname].eu
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 

Thread Tools




All times are GMT. The time now is 10:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org