Bug#919951: marked as done (ocaml builder must not be called `dune' or provide /usr/bin/dune)
Your message dated Mon, 25 Feb 2019 11:47:56 -0600 with message-id <20190225174755.gd7...@mosca.iiec.unam.mx> and subject line Re: Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune has caused the Debian Bug report #919951, regarding ocaml builder must not be called `dune' or provide /usr/bin/dune to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 919951: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919951 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: tech-ctte In #919622 and the associated debian-devel thread, "Conflict over /usr/bin/dune" https://lists.debian.org/debian-devel/2019/01/msg00227.html the file conflict over /usr/bin/dune was discussed. The rough consensus of the debian-devel thread was that /usr/bin/dune ought definitely not to be taken by the ocaml build system, and that the best claim on it was the C++ library which already provides a number of /usr/bin/dune?* binaries. Instead, the maintainers of the ocaml package reassigned the bug against their `dune' package to the whitedune package, which previously provided /usr/bin/dune as a compat symlink. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622 They used the phrase "As discussed on debian-devel" which is very misleading because it makes it sounds like there was a consensus for this course of action, whereas the opposite is true. Apparently as a result of this there was an NMU of `whitedune' to drop the symlink /usr/bin/dune. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58 The maintainers of the ocaml `dune' have now uploaded `dune' (the ocaml package) with /usr/bin/dune and Breaks+Replaces to claim the file. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#99 Meanwhile there seems to have been no contact with the maintainers of the C++ library which is the only hit on Wikipedia for https://en.wikipedia.org/wiki/Dune_(software) (Amazingly, this is still true at the time of writing even though I referred to this fact in the debian-devel thread.) Note that this ocaml tool `dune' was previously known as `jbuilder'. It has nothing to do with Java AIUI. No-one has suggested a plausible charitable explanation for why the ocaml upstream made such egregiously bad naming mistakes twice in succession. Additionally the binary package name `dune' for the ocaml tool is bad, too. Please would the Technical Committee: * Declare that no-one is allowed the name /usr/bin/dune other than the C++ library dune-common or its friends. * Declare that no-one is allowed the binary package name /usr/bin/dune other than the C++ library dune-common or its friends. * Declare that the ocaml build system should choose a new source package name and use it henceforth. I am about to file an RC bug against the `dune' package, blocked by this one. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. --- End Message --- --- Begin Message --- Bug report #916468 on the ownership of the /usr/bin/dune command was opened after a quite short discussion in debian-devel¹. ¹ https://lists.debian.org/debian-devel/2018/12/msg00190.html The Technical Committee has evaluated the situation that led to the opening of said bug as well as this one (#919951), and in accordance with the Procedure for the Technical Committee, 6.3.6 of the Debian Constitution: The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. Together with a review of the resolution of #916468 and the last messages in #919951, the Technical Committee recognizes the situation as happily solved thanks to the direct interactions and good will of both the maintainers and upstream authors of the affected packages. Thus, not having a controversy to decide upon anymore, we have decided to mark this bug as Closed. Furthermore, the Technical Committee considers that, given the very short discussion the involved parties had before raising this issue to the Committee, we should remind our fellow Developers that any decision reached by the Technical Committee can be seen to some as an imposition. We urge everybody to always seek a decision by a serious, calm discussion before escalating issues. signature.asc Description: PGP signature --- End Message ---
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Dear Technical Committee members,
I call for vote immediately on the following resolution.
=== Resolution ===
The Technical Committee resolves to decline to override the debootstrap
maintainers.
Furthermore, using its §6.1.5 "Offering advice" power, the Technical
Committee considers that the desirable solution at the time of `bullseye` is:
* W: `weak`: both directory schemes are allowed, but packages should only
be built on hosts with classical directory schemes (or in such
chroots)
* M: `middle`: both directory schemes are allowed, and packages (including
official packages) can be built on hosts with either classical
or "merged `/usr`" directory schemes
* H: `hard`: both directory schemes are allowed, but packages should only
be built on hosts with "merged `/usr`" directory schemes (or in
such chroots)
* FD: Further Discussion
=== End Resolution ===
=== Rationale ===
## What is "merged `/usr`"
"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:
* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between
`/` and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what
_needs_ to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.
[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge
The arguments against moving the base directories' scheme towards "merged
`/usr`" are as follows:
* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system
files in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.
The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example
i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.
## "merged `/usr`" in Debian
In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for
simply dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:
* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks
by default when using debootstrap >= 1.0.102.
The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.
It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.
[2]: https://tracker.debian.org/pkg/usrmerge
## Issues from "merged `/usr`"
Since the default change in debootstrap 1.0.102, some issues
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
(Corrected the recipients, these mails should go to the bug). Le lundi, 25 février 2019, 14.23:31 h CET Didier 'OdyX' Raboud a écrit : > Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit : > > > * B: The desireable solution at the time of bullseye is `hard`; both > > > directory schemes should be allowed, and packages can be built on hosts > > > with either classical or "merged-`/usr`" directory schemes. > > > > Isn't this the 'middle' option above rather than 'hard'? > > Actually, it's both. The only difference between 'middle' and 'hard' is > that in 'middle', _official_ packages can be built on either directory > schemes, where in 'hard', they are only built on "merged-`/usr`" directory > schemes. > > The distinction I was trying to make in the table is the following: > > * on which directory scheme Debian would build its "official" packages on > (columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is > "both", 'hard' is "merged-/usr". > * whether .debs built on A can break on B (columns 7 & 8). All of 'weak', > 'middle' and 'hard' long-term statuses allow .debs to be built from either > directory scheme and be installed on either without constraints Wrong, actually (hit send too fast). The intent behind 'weak' was: "merged-/ usr" is allowed, but packages built on these directory schemes can break on classical directory schemes. So that should have read: * whether .debs built on A can break on B (columns 7 & 8). 'middle' and 'hard' long-term statuses allow .debs to be built from either directory scheme and be installed on either without constraints; 'weak' permits "merged-/usr" directory schemes, but packages built there can break on classical directory schemes. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit : > > * B: The desireable solution at the time of bullseye is `hard`; both > > directory schemes should be allowed, and packages can be built on hosts > > with either classical or "merged-`/usr`" directory schemes. > > Isn't this the 'middle' option above rather than 'hard'? Actually, it's both. The only difference between 'middle' and 'hard' is that in 'middle', _official_ packages can be built on either directory schemes, where in 'hard', they are only built on "merged-`/usr`" directory schemes. The distinction I was trying to make in the table is the following: * on which directory scheme Debian would build its "official" packages on (columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is "both", 'hard' is "merged-/usr". * whether .debs built on A can break on B (columns 7 & 8). All of 'weak', 'middle' and 'hard' long-term statuses allow .debs to be built from either directory scheme and be installed on either without constraints > FWIW I think I'm OK with recommending 'middle' but 'hard' seems over > the top. Ideally there should be no difference in building on merged > /usr hosts vs. classical ones. I concur with your ideal. I'll add this option on the ballot. > As for buster and overriding the debootstrap maintainers on the default: > > I think being able to do local builds that work on other Debian > systems with minimal fuss (no chroots etc.) is a desirable property > but not an absolute requirement. I'd certainly love to see all the > 'paths_vary_due_to_usrmerge' issues fixed for buster [1]. I concur. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
