Hi, Am Thu, Sep 03, 2026 at 09:11:17AM +0900 schrieb Charles Plessy: > most of the Bioconductor transition went smoothly, but unfortunately it > clashed > with the HDF5 transition.
:-( > When Bioconductor was released, it contained core packages shipping a vendored > version 1.14 of HDF5, which was very close to the one in Testing. Unvendoring > was very easy. After the Bioconductor transition started, the HDF5 transition > took place and now we have version 2.1 in testing, and I simply do not have > the > skill to unvendor HDF5 in Bioconductor and do the major upgrade instead of > upstream themselves. I am CCing debian-r@ and [email protected] to > see if somebody else wants to pick the ball, but I am pessimistic about this. > > The next Bioconductor release might solve the problem, or might not. The > next-next release will be in April. Really in April? In item 2 you write "next month" and as far as I understood there are two releases per year. > I think that our possibilities are: > > 0 Someone unvendors HDF5 in Bioconductor and ports the dependencies to be > compatible with the major upgrade to1 version 2.1. I tried with Claude > 4.8 in > OpenCode and failed after spending 20$ of OpenRouter tokens, but my AI > skills > are still beginner level… This sounds complex and trusting AI only seems to be a bad idea. > 1 Ship the r-bioc-* packages with their vendored HDF5 library and trust that > they will handle major security issues well. The Bioconductor project has > good > programmers, more than a decade of acheivements, and a full commitment to > security. Also, they might migrate before the Freeze. I like this pragmatic approach. I'd prefer to talk to Bioconductor developers what they might think and what schedule they intend to follow. > 2 Leave the r-bioc-* packages depending on r-bioc-rhdf5lib in Sid, migrate > the > rest and call the transition done. The next one is next month. Revisit > the > issue before the Freeze. Might be an option I would rank below the former option. It has the problem that we might loose time before the Freeze which we could use now (by talking to Bioconductor developers). > 3 Remove r-bioc-rhdf5lib and its dependencies from Debian until we can > unvendor HDF5. The NEW queue is very efficient those days. If its only $ apt rdepends r-bioc-rhdf5lib r-bioc-rhdf5lib Reverse Depends: Depends: r-bioc-rhdf5 (>= 1.33.3) Depends: r-bioc-alabaster.base Depends: r-bioc-rhdf5filters Depends: r-bioc-alabaster.base Depends: r-bioc-hdf5array Depends: r-bioc-dropletutils I do not see a big problem in not shipping these for some time. On the other hand since some time r-bioc-rhdf5lib has a popcon > 200 which is above a lot of other Debian Med packages. > 4 Give up and remove all r-bioc-* packages from Debian. There are excellent > third-party repositories shipping them. In that case we may need to move > some > non-R dependencies to contrib, or remove them too. I'm not convinced that this is in the interest of our users. > My favorite is option 1. Same here. Kind regards Andreas. -- https://fam-tille.de
