First, I hear your frustration.
I suspect that our current path is going to lead to a fair bit of pain,
sufficient even that I expect us to make some changes after the release
of buster. Swallowing that will be hard, but I tend to think we're
being somewhat narrow in which requirements are being considered by the
current plan, and we'll realize that we're not serving the needs of
significant user communities with our current approach.
>>>>> "Guillem" == Guillem Jover <guil...@debian.org> writes:
Guillem> On Sun, 2019-02-24 at 09:23:14 -0500, Sam Hartman wrote:
>> >>>>> "Guillem" == Guillem Jover <guil...@debian.org> writes:
Guillem> On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote:
>> >> Guillem Jover writes: > You are still conflating the concept
>> with >> the deployment. The > underlaying properties of merging
>> /usr is >> that the contents for > directories that are present
>> in both / >> and /usr get merged into > /usr. >>ยท >> No, I'm
>> saying that you are proposing yet another different file >>
>> system layout. Which is quite simple to see: the file system >>
>> would differ.
>> >>
>> >> You just claim it follows similar "ideas" in some way.
>>
Guillem> Again, no, the important part is that the contents get
Guillem> *moved* properly and *automatically* within the .deb
Guillem> packags,
>>
>> This is the important part to *you*.
Guillem> This (and the other part you omitted) was an attempt at
Guillem> describing how this alternative deployment method follows
Guillem> the same underlying concept. And not about how it is
Guillem> important to me.
Guillem> Sure (even though that was unrelated to my point), and I've
Guillem> acknowledged that in previous threads. I do understand some
Guillem> people might value using a deployment method that gives
Guillem> immediate results so they can use the underlying properties
Guillem> of the merged-/usr right away, and providing a readily
Guillem> packaged solution for that seemed acceptable (even though
Guillem> it complicates packaging and alternative deployments). I
Guillem> can also see the apparent appeal of using directory
Guillem> symlinks, as that avoids the forest of compat symlinks.
I don't have a formal definition of deployment vs concept.
However, I think they are similar to concepts of design+requirements vs
implementation. (Implementation is similar to what you're calling
deployment, design/requirements are I think what you're similar to
calling concept).
That boundary between design and implementation depends on your
requirements.
In your model, both /bin/true and /usr/bin/true might exist and be
different inodes. One would be a symlink, one would be presumably a
binary.
In the usrmerge model, that situation never exists. Instead, if on a
non-usrmerge system, /usr/bin/true doesn't exist, but on a usrmerge
system, /bin/true and /usr/bin/true are the same filesystem entity.
What people are telling you is that they consider that a requirement,
not a detail of the implementation--in your words, they consider that
part of the concept.
I do agree that you are repeating yourself. I might suggest focusing on
asking *why* people feel this is part of the concept rather than an
implementation detail. I understand if you're too frustrated or
burned-out to do that, but I'd suggest that would be a good next step
for someone holding your position.
For myself, I consider that important because I believe that managing
the dependencies of the sort of transition you talk about would be more
difficult than the pain of the current approach. Say that the next
version of bash goes and moves bash to /usr/bin/bash with a
compatibility symlink. We now have a more complex problem with build
systems. Today, if you build on a usrmerge system, you run into the
possibility that /usr/bin/bash will be discovered by a build system.
You can avoid this class of problems by not building on a usrmerge
system. In your deployment, once that package enters the archive, I
need to either guarantee that my build system won't choose
/usr/bin/bash, or I need to depend on a new enough version of bash that
I'm guaranteed to get /usr/bin/bash. Moreover, because the state space
of packages that are converted and not is larger, the reproducible
builds approach of testing to see if a build veries in this condition is
a lot harder to implement.
In addition, I find the eventual /bin -> /usr/bin symlink critical.
Interfaces like #!/bin/sh are long-standing conventions in POSIX. We
should not deprecate those interfaces. Maintaining a certain small set
of compatibility symlinks for common interfaces like /bin/sh is
unappealing. Users will not know which /bin entries they can depend on.
Also, users familiar with AIX or other Linux distributions that do have
a /bin->/usr/bin symlink will assume that they can depend on /bin/foo
for anything in /usr/bin. I think the value of making things simple for
users in the eventual usrmerge world is helpful.
(There's a whole different set of issues that we'd need to talk about if
we plan on maintaining both usrmerge and non-usrmerge on an ongoing
basis rather than doing a transition.)
