[openfst] On Fri, Aug 18, 2017 at 03:44:43PM +0200, Giulio Paci wrote: > > How are you going to handle the transition? Have you tried rebuilding your > > reverse dependencies? If not, should I do that for you? > > I had not, but I did today. > > phonetisaurus is not building and will require an update in order to make > it work with openfst 1.6.3. I talked with upstream and there are a lot of > unreleased updates (probably there will be a new release next week). > Unfortunately the build system and requirements have several differences > from the current packaged version, so it will require some time to fix > this package.
I see that phonetisaurus is only in experimental. This means it's not a show stopper -- otherwise, we'd be for a nasty transition that'd require either packaging the old version of the library or at least temporary removal of phonetisaurus. > opengrm-ngram is not building with gcc-7, but I have already packaged the > latest upstream release, that fixes gcc-7 compilation and that compiles > with openfst 1.6.3. It'd have to be uploaded only after openfst makes it through NEW again (binNEW processing is done pretty quickly). Otherwise, we'd need a round of binNMUs on all architectures. > > As you maintain all of the rdeps, you'll handle the transition as a single > > block, right? > > I guess we should upload openfst and opengrm-ngram at the same time (even > now). > I will need more extensive work for phonetisaurus and I am not currently > able to predict when that package will be ready. > > How do you suggest to deal with this situation? Let's upload openfst now, then opengrm-ngram once openfst passes binNEW and hits the buildds. phonetisaurus can be ignored for now -- it will be uninstallable but people who already have it installed have libfst4 which satisfies its needs. Does this sound good to you? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver! ⠈⠳⣄⠀⠀⠀⠀
