Bug#923091: That merged-usr is mandatory is RC
Hi,
Given that there is still discussion about the impact of merged /usr at this
very late point of the freeze, I think having merged /usr by default for new
installations should be reconsidered.
On Sun, May 19, 2019 at 07:22:08AM -0400, Sam Hartman wrote:
> I've been debating doing this, but continue to believe that it's
> important after several days of pondering. So, per constitution 5.1
> (2), I'd like to explicitly lend support to the idea that it would be
> really good if we provide our users a way to install buster without
> merged /usr. I think that if we do not do so now, we need to be open to
> the possibility that if users are stymied in doing their work, we will
> need to do so in a buster point release even if we would not normally
> add something some might consider a feature in a point release.
>
> I'm not speaking to whether I think it should be RC or even whether an
> expert only option is good enough.
> I am simply saying that with my DPL hat on, I think this issue is
> important enough it deserves real consideration.
>
>
> I think that the TC's ruling and ongoing experience suggests we have
> carefully considered how we want to approach merged /usr for our own
> internal work developing Debian and come to a position that at least for
> the moment seems to be working.
>
> What I'm most concerned about is people who use Debian to develop
> software they plan to use on Debian but who are not part of Debian.
> Examples of this include people within organizations who build programs
> to distribute within their organization. People who build upstream
> programs using configure from source. That sort of thing.
>
> These people may not use packages. These people may not use chroots.
People who develop software often do this on different machines than the one
the software runs on. When the production server gets upgraded, and a new
development machine is installed, one will have merged /usr and the other
doesn't. This probably isn't very good. Having an option to change this during
the install probably won't help these users.
In general, I think that if merged /usr is the default for new installations
for a Debian release, it should be the default on upgrades to that release as
well. This is not the case for buster. Obviously changing the default on
upgrades needs carefull planning and should be started at the beginning of a
release cycle.
> They are our users; they are our priority. Even if we believe using
> chroots or containers would be better for them, I don't think we should
> force people into changing their build processes.
>
>
> I don't think we have a good idea how big the impact will be for these
> users, and so, I think we should be conservative.
>
> If we don't choose to be conservative, I think we should be extra
> willing to revisit our decision if we find we are wrong.
Please note that there were a number of bugs triggered by merged /usr that
were discovered during the freeze. Most of them were actual bugs in the
packages, but they were (only) triggered with merged /usr. The fact that they
were only discovered late in the release cycle isn't a good sign.
> Again, all I'm saying is that I think this issue is important enough to
> consider seriously. I am not in a position to balance this issue
> against other things before us.
> I'm speaking as the DPL because I'm trying to consider something that is
> a project level concern. However, this statement has no actual force as
> clearly spelled out in the constitution.
> I'm speaking in the hopes of getting people to take a moment, think
> about this issue and come to their own conclusions.
Having an option to allow experienced user to change the default doesn't
really solve this. So the way forward is to change the default back to not
having merged /usr on new installs.
Thanks,
Ivo
Reply to: