On 18-03-14 10:18:24, Antonio Terceiro wrote:
> On Wed, Mar 14, 2018 at 11:36:14AM +0100, Georg Faerber wrote:
> > 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?
>
> I don't think there is a way around that, since the new package is not
> a drop-in replacement for the old ...
Alright.
> > Reverse dependencies are then able to change their dependency
> > anytime they wish.
>
> yes, but ideally we want to push that, hence my suggestion of
> reporting bugs etc. depending on your motivation levels you may want
> to make this transition a personal quest. ;-)
Sure, I'll do this, and planned to do so anyway, but I'll start with
this after the new packages is available in the archive.
Thanks,
Georg
Attachment:
signature.asc
Description: Digital signature