>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> (sending this because I got the release team address wrong) Ian
Ian> Jackson writes ("That merged-usr is mandatory is RC"):
>> Control: severity -1 serious
>>
>> In #923091, Guillem (with dpkg maintainer hat on) asks for a
>> base-installer option to allow installing buster without
>> merged-usr.
>>
>> Guillem filed the bug as `wishlist' but given the controversy it
>> seems to me that it should be RC if for no other reasons than
>> social cohesion.
>>
>> CCing the TC FYI (they have already been involved in merged-usr
>> debates via #914897) and the release team, in case they have an
>> opinion. FAOD I am not a maintainer of base-files but AFAICT the
>> base-files maintainer has not expressed an opinion about
>> severity.
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.
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.
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.
--Sam
signature.asc
Description: PGP signature
