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

[Petr Hracek]

On 05/30/2013 10:07 AM, Petr Hracek wrote:
> 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.
>

I have forgot that now I have to find out any proven packager
which can built up most of the packages
with that new library by fedpkg chain-build.

-- 
Best regards / S pozdravem
Petr Hracek