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

Petr Hracek phracek at redhat.com
Thu May 23 13:29:07 UTC 2013


On 05/23/2013 10:23 AM, Peter Robinson wrote:
> On Wed, May 22, 2013 at 7:58 PM, Adam Williamson <awilliam at redhat.com> wrote:
>> On Wed, 2013-05-22 at 11:01 +0200, Petr Hracek wrote:
>>
>>>>> The issue is that once this is in, all the 306 packages above will have
>>>>> broken dependencies. And it's not just simple rebuilds that are
>>>>> required; we'd need _ordered_ rebuilds in dependency order: build deps
>>>>> that require the old libpng can't be installed in the koji build roots
>>>>> without rebuilding them first. And this means individual package
>>>>> maintainers can't fix their packages before someone has fixed things
>>>>> down in the dep chain.
>>>> The way it was done last time on the 1.5 upgrade was to have a
>>>> compat-libpng package that had the 1.5 release so that nothing broke
>>>> while things were rebuilt and then once the vast majority of the
>>>> rebuild happened it was then dropped to avoid this problem.
>>>>
>>>> Peter
>>> well but when side tag is used then no compatibility package is needed
>>> Rawhide will not be broken in that case.
>>> I think that there are two ways how to handled that issue:
>>> - create side tag and after finishing merge changes into the rawhide
>>> - create a compatibility package in rawhide and when migration will be
>>> done that compatibility package will be dropped.
>>>
>>>   From my point of view side tag is better to handlling.
>> Either works. The drawback of a side tag is that it's slightly more
>> complex to work with. The drawback of a compat library is the lack of
>> motivation to complete the migration: there's a danger when you
>> introduce a compat library that there isn't sufficient motivation for
>> people to migrate their packages to the new library, because hey,
>> everything works, right? What's the big rush?
> You still need a compat package with the old API in the side tag as
> well as you still need to have the old soname around until at least
> all the packages in the core build root can install.
That's my misunderstanding. I thought that in side tag compat package
will not be needed.

All packages will be build up against new libpng package in side tag.
Why compat package will be needed? Is there any reason?

Proven packager will rebuild affected packages against the newest libpng.

It is really not so clear for me.
After merging to the rawhide we will have only the newest  libpng package
and all packages will be build up against new libpng.

Another question:
Let's say that in rawhide I will create libpng compat package.
What is the good time to make them deprecated?


>
>> I think we've got into situations in the past where we've had to retire
>> a compat library before everything was migrated off it, just to force
>> people to _actually migrate things off it_.
> Yea, ultimately the compat package is there primarily to get all the
> core build systems stuff built against the new soname so that things
> will work and then there's not much point in keeping it around because
> it ultimately allows procrastination.
>
> Peter


-- 
Best regards / S pozdravem
Petr Hracek



More information about the devel mailing list