Bug#863965: marked as done (RM: usrmerge/13)
Your message dated Sat, 03 Jun 2017 18:09:00 +0000
with message-id <1286c0db-1ad4-766e-e865-9411b581ece1@thykier.net>
and subject line Re: Bug#863965: RM: usrmerge/13
has caused the Debian Bug report #863965,
regarding RM: usrmerge/13
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 owner@bugs.debian.org
immediately.)
--
863965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863965
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: rm
Disclaimer:
The maintainer of usrmerge disagrees with me on that.
Several people convinced me that I did not have the
power to reopen #863269 and that doing so was wrong,
therefore I am opening this bug here to ask as suggested
for an explicit decision of the release team that has the
power to remove packages from stretch even when there is
no bug open against the package.
I am hereby asking for a decision that results in the closing
of this bug by a member of the release team in time for the
stretch release, either with or without removing usrmerge
from stretch.
While merged /usr seems to be the future and will likely be the
default in buster, shipping the usrmerge package in stretch
wouldn't bring real benefits to users while creating situations
where the only proper solution for a user might be to reinstall.
There are several known breakages with merged /usr (check the
blockers of #86326), and these would have to be fixed for stretch.
Additionally, there is also an unknown number of runtime bugs
like #860523 where code makes path assumptions that break with
merged /usr. And there is no good way to find these automatically,
only a longer time of merged /usr as default in testing/unstable
would find them.
The worst part is that the merged /usr via "apt-get install usrmerge"
is irreversible, and having to tell users of stable that they have
to reinstall for reverting it would be a huge blow for the stable
reputation of Debian.
--- End Message ---
--- Begin Message ---
Adrian Bunk:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: rm
>
> [...]
>
> While merged /usr seems to be the future and will likely be the
> default in buster, shipping the usrmerge package in stretch
> wouldn't bring real benefits to users while creating situations
> where the only proper solution for a user might be to reinstall.
>
> There are several known breakages with merged /usr (check the
> blockers of #86326), and these would have to be fixed for stretch.
>
> Additionally, there is also an unknown number of runtime bugs
> like #860523 where code makes path assumptions that break with
> merged /usr. And there is no good way to find these automatically,
> only a longer time of merged /usr as default in testing/unstable
> would find them.
>
> The worst part is that the merged /usr via "apt-get install usrmerge"
> is irreversible, and having to tell users of stable that they have
> to reinstall for reverting it would be a huge blow for the stable
> reputation of Debian.
>
I agreed in that I do not believe the risks do not outweigh the benefits
of shipping usrmerge in stretch.
Hopefully things will look different in buster.
Thanks,
~Niels
--- End Message ---
Reply to: