Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0
phracek at redhat.com
Thu May 30 08:07:40 UTC 2013
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  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,
>>  https://bugzilla.redhat.com/show_bug.cgi?id=964161
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
More information about the devel