Re: Proposing patch for packages, affected by transition
Hi,
>Okay. But if they apply this patch right now, package will not build
>aganist unstable. Is it okay?
just mention that in the bug report, this will allow me/you to NMU when the transition starts
> FAIL camldbm_1.0-2.dsc -- patch ready
> FAIL courier_0.73.1-1.6.dsc
> FAIL freeradius_2.2.8+dfsg-0.1.dsc
> FAIL ifmail_2.14tx8.10-22.dsc
> FAIL nis_3.17-34.dsc
> FAIL ntop_5.0.1+dfsg1-2.1.dsc
> FAIL ocsigenserver_2.4.0-1.dsc
> FAIL perdition_2.1-2.dsc
> FAIL python3-stdlib-extensions_3.4.2-1.dsc
> FAIL qsf_1.2.7-1.dsc
> FAIL ruby2.1_2.1.5-2+deb8u2.dsc
> FAIL ruby2.3_2.3.1-5.dsc
> FAIL sortmail_2.4-2.dsc
>
>No. -2 version separated modern and compat interface into different
>binaries packages, so some packages at least need add build-depends:
>libgdbm-compat-dev.
if adding an additional build dependency works, I'm ok with a bug filing
(maybe send a mail to -devel, because this sounds like an MBF)
BTW since there are >10 packages to patch, what about make the new library depend explictly
on the old one?
does this fix all of them? in this case I would think about
transition the new version, and open bugs against the packages with wishlist severity
do another "transition" when the first one is migrated, and NMU packages that didn't update
their control file.
remove the dependency from the main library to the compat one.
(and all of this workflow has to be eventually acked by -release)
But yeah, since they are around ~10, I'm good in NMUing some of them, assuming the maintainers
will take care of most packages (e.g. ruby)
Gianfranco
Reply to: