Hi, > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > The winners are: > Option M `middle` > Option H `hard` > > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Dear Marga, as Chair, could you please make use of your casting vote to break > this tie?
I'm using my casting vote to vote in favor of M `middle` (i.e. consider that the desirable situation at the time of bullseye is that both directory schemes are allowed, all packages can be built on either). My rationale for taking this decision is as follows: Right now we are not ready to migrate to building on merged-usr systems in Debian, there are still 29 known packages that are broken and need to be fixed. My expectation is that those packages will be fixed in the not so distant future (i.e. before bullseye) and that after that, the buildd profile in debootstrap will default to having a merged /usr, so that new buildd chroots will use that setup. However, we have no control over how fast individual developers and derivative distributions will migrate to the new format. It's possible that more time will be required until everyone is ready to migrate. Additionally, as of our current understanding of the issue, there are no known problems for building on a non-merged system. Supporting this setup does not imply additional work from the point of view of our maintainers (for now). In the future, it would be a bug if a problem is discovered with building a package on a non-merged /usr system. I understand that this would mean additional work to the maintainers of such a package, but at least as of today this is a non-issue. Eventually, when fixing such bugs becomes a significant burden for our maintainers, it can be decided that the setup is no-longer supported, but my personal recommendation would be to wait at least until bullseye+1. That's why I'm voting "Middle" for bullseye. -- Thanks, Marga
signature.asc
Description: PGP signature
