Fwd: goose koji inheritance

10 views
Skip to first unread message

Clint Savage

unread,
Jun 20, 2013, 9:41:54 PM6/20/13
to GoOSe Project

let's try that again
>
> here is what koji inheritance probably should look like

IMG_20130620_193558.jpg

Mathieu Bridon

unread,
Jun 20, 2013, 11:18:31 PM6/20/13
to goose...@googlegroups.com
On Thu, 2013-06-20 at 19:41 -0600, Clint Savage wrote:
> let's try that again
> >
> > here is what koji inheritance probably should look like

Why do gl6.{1,2}-updates inherit from gl6.{1,2}, while gl6.0-updates
does **not** inherit from gl6.0 ?


--
Mathieu

za...@oglesby.co

unread,
Jun 20, 2013, 9:43:06 PM6/20/13
to goose...@googlegroups.com
Wow…a napkin!


On Jun 20, 2013, at 9:41 PM, Clint Savage <her...@gmail.com> wrote:

let's try that again
>
> here is what koji inheritance probably should look like


--
You received this message because you are subscribed to the Google Groups "GoOSe-Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to goose-linux...@googlegroups.com.
To post to this group, send email to goose...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
<IMG_20130620_193558.jpg>

Clint Savage

unread,
Jun 21, 2013, 12:01:29 PM6/21/13
to GoOSe Project
Mathieu,

The reason is that gl6.0-updates packages will be tagged after they are built into gl6.0-updates-candidates and tested. In this way, we can have updates separate with inheritance for the generic updates repo. Essentially, everything is built and tested in the left tags and is moved to the appropriate -updates tag as it's approved. Then we can mash the updates repos together and keep the iso repos (gl6.x) separate.

Cheers,

Clint




--
Mathieu

Clint Savage

unread,
Jun 21, 2013, 12:01:53 PM6/21/13
to GoOSe Project
Actually, Zach, it's a placemat! :)

herlo

Mathieu Bridon

unread,
Jun 23, 2013, 12:07:58 AM6/23/13
to goose...@googlegroups.com, Clint Savage
On Saturday, June 22, 2013 12:01 AM, Clint Savage wrote:
> Mathieu,
>
> The reason is that gl6.0-updates packages will be tagged after they are
> built into gl6.0-updates-candidates and tested.

But that's the same thing for gl6.{1,2}-updates: packages there will be
tagged after they are built into gl6.{1,2}-updates-candidates and tested.

> In this way, we can have
> updates separate with inheritance for the generic updates repo.
> Essentially, everything is built and tested in the left tags and is moved
> to the appropriate -updates tag as it's approved. Then we can mash the
> updates repos together and keep the iso repos (gl6.x) separate.

It seems you're explaining the need for two sets of tags: gl6.{1,2} and
gl6.{1,2}-updates.

Indeed, this separation is what allows making an ISO from gl6.{1,2}
while publishing updates in gl6.{1,2}-updates.

But that wasn't my question. :)

Let me reformulate:

* gl6.0-updates **does not** inherit from gl6.0
* gl6.1-updates **does** inherit from gl6.1
* gl6.2-updates **does** inherit from gl6.2

My question was: why the differences in inheritance schemes?

( I'm sure I'm simply missing something obvious here, but I can't figure
out what ^_^ )


--
Mathieu

Clint Savage

unread,
Jun 23, 2013, 1:29:25 AM6/23/13
to Mathieu Bridon, GoOSe Project
Mathieu,

To answer your question, you are on the right track. It's about separating inheritance...sort of.

We want to build with every package we can, thus we have gl6.1 which inherits from gl6.0-updates-candidate which inherits from gl6.0. The idea here is that we need the updates, or possibly do anyway, to build gl6.1 packages from gl6.0 and it's updates. However, the problem comes from the fact that we need to be able to keep updates separate from the ISOs when we're a) distributing new ISOs, and b) spinning release/update repositories.

Anything in gl6.x and gl6.x-updates-candidate will be also tagged into gl6.x-updates. Essentially, we'll only keep updates in one repo, that will be the latest gl6.x-updates tag, with inheritance.

I hope this explains the reasoning for the separate inheritance. Essentially, we're just doing it so we can keep updates separate. It's actually similar to what Fedora does with bodhi, at least from what I can tell.

Cheers,

herlo
Reply all
Reply to author
Forward
0 new messages