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? 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_. But both approaches work, and both are massively better than just breaking half of Rawhide :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
