On 18-03-13 16:30:16, Antonio Terceiro wrote: > On Sun, Mar 04, 2018 at 10:04:46PM +0100, Georg Faerber wrote: > > On 18-03-03 16:30:36, Cédric Boutillier wrote: > > > ruby-factory-girl-rails fails to build because of dependency checking > > > looking for a factory_girl gemspec file instead of a factory_bot. > > > > > > I don't know if it is better to fix factory-girl-rails gemspecs, or to > > > ship also the factor_girl.gemspec file too with ruby-factory-bot. > > > > Hm, I'm not really sure how to deal with this, as I already (tried?) to > > describe in one of my initial mails: Not only to name changed, but also > > code within, and no "compat helper / level" was introduced. This means, > > that code which depends on factory_girl needs to change as well. > > Upstream described the necessary steps regarding this [1]. > > > > Given these circumstances, I'm not really sure if using 'Replaces' in > > d/control and providing a transitional package is the right way to go. > > > > What about introducing ruby-factory-bot as a new package without > > 'Breaks', 'Replaces' and a transitional package, and removing > > ruby-factory-girl once all upstreams of the reverse dependencies have > > changed to ruby-factory-bot? > > If the new package is not backwards compatible, it should not have > breaks/replaces or anything like that. you need to make the old package > deprecated, report bugs against reverse dependencies, and wait for them > to switch to the new library.
Alright -- so I'll create an ITP and package ruby-factory-bot accordingly? After this, both ruby-factory-{bot,girl} will exist in the archive then, but I guess this is okay? Reverse dependencies are then able to change their dependency anytime they wish. Thanks, Georg
signature.asc
Description: Digital signature