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

[Peter Robinson]

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.

> 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