Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0

[Petr Hracek]

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