Hi Lorenzo, On Sun, Sep 24, 2023 at 08:14:46PM +0200, Lorenzo wrote: > > If doing this, your base-files-unmerged would have to declare > > Replaces, Conflicts and Provides with base-files and fully replace its > > functionality. Otherwise, it would cause a file conflict on /bin, > > which will become a symbolic link in base-files. Alternatively, it > > could install diversions for these locations to avoid that file > > conflict scenario, but installing diversions for directories is not > > supported by dpkg, so you have to go through some hoops to make it > > work. > > I assume you're saying such package, if properly done, will be allowed > to exist in experimental/unstable.
I am not a gatekeeper of those suites and cannot make such a statement. Declaring a conflict with an essential package definitely raises eyebrows though and making apt install this is a non-trivial affair. That said, the usrmerge package still violates assumptions of dpkg and was/is allowed. > > Furthermore, it should declare Breaks with systemd to avoid > > being pulled into usual installations accidentally. > > Isn't a Breaks with systemd-sysv enough? Is there a problem with > debootstrap or similar tools? > Declaring a Breaks with systemd will make it very hard to have an > autopkgtest that runs automatically on salsa for this package.. The answer to this question is not obvious to me. Your reasoning makes sense to me. On the flip side, systemd upstream will soon drop support for split-/usr. If you were not declaring such Breaks, I'd assume that systemd maintainers would want to declare the reverse Breaks having the same effect. The implications of continuing to maintain a split-/usr variant of Debian are very unclear to me. I have not spent much thought on this and my interest in doing so is fairly limited. That said, if you request changes to DEP17 to make split-/usr easier, I'll be looking into their feasibility. Helmut
