On 05/22/2013 09:51 AM, Petr Hracek wrote:
Thank you for really deep explanation.
We had discussion how to do that issue
and we will created a side tag for that.
Compatibility package will not be needed and BZ will be closed.
Best regards / S pozdravem
Petr Hracek
On 05/21/2013 03:43 PM, Kalev Lember wrote:
> 2013-05-20 09:03, Petr Hracek skrev:
>> Just a one short question.
>>
>> You are talking about side tag.
>> Could you please describe me what are you talking about?
>> It seems like I am a newbie.
> Koji organizes builds by labelling them with tags. There's a a tag for
> f19, a tag for f19-updates, a tag for f20, and a number of others. These
> decide what repository packages from a particular build end up in.
>
> For rawhide, all packages that are built get automatically tagged with
> the f20 tag, and this is what causes newly built packages to appear in
> the rawhide build roots and in daily rawhide composes.
>
> Earlier you "untagged" your libpng 1.6 build and that was enough to
> remove it from the repos.
>
> What Adam means is that it's possible to ask the koji admins to create a
> new side tag + a separate build target in koji, so that the libpng 1.6
> rebuilds could happen without disturbing the regular rawhide repos.
>
> Such side build targets can be used to handle soname bumps: A library
> package with a soname bump is tagged with the side tag and appears in
> the side target, then all consumers are rebuilt against the new library
> using the side build target, and finally once all is done, the new
> builds are tagged back into the main rawhide all together.
>
> In this case however I think it's not necessary to have a side tag. You
> are already working on a compatibility libpng15 package [1] and that
> removes the need to rebuild everything at once -- with that in place,
> builds can happen slowly, over time. The side tag makes sense if you do
> _not_ want to provide the compatibility library.
>
> Hope this helps,
> Kalev
>
> [1]
https://bugzilla.redhat.com/show_bug.cgi?id=964161
>
Ok, well.
It seems that libpng15 compatibility package is built in rawhide.
What are the next steps?
Tagged already built libpng(1.6) package?
I do not want to break rawhide completely and
I would like to avoid all mistakes which can be done from my side.
If I understand whole process then I can tagged libpng package again
and create a lot of bugzillas for support libpng1.6, right?
I will make a notes what to do that in the future of course.
--
Best regards / S pozdravem
Petr Hracek