On Mar 21, Adrian Bunk <b...@debian.org> wrote:

> Merged /usr does not seem to be ready for a stable release right now.
I disagree: it works quite well.

> Not limited to this bug, my general impression of the current state of 
> merged /usr is that it mostly works - but it is not yet in a state that
> it should be used by normal users of Debian stable on production systems.
Even if this were true, since it is not enabled by default I do not 
believe that it would be a concern.

> a) be a properly supported and tested feature - including that
>    problems only visible with merged /usr are considered RC, or
Not every bug is RC.

> The usrmerge package contains versioned Conflicts on pre-stretch 
> packages, but the unversioned Conflicts on packages that are still
> broken in stretch won't work in scenarios like:
The packages which are still not compatible are:
- ksh: a trivial patch was provided over one year ago, but the 
  maintainer refuses to merge it
- safe-rm: a patch was provided but the maintainer is unsure about how 
  to fix the package
- molly-guard: same problem (and same maintainer) of safe-rm

I am sure that both safe-rm and molly-guard could be fixed, but I just 
have not had yet a personal interest in spending a few hours on them.

>   apt-get install usrmerge
>   apt-get remove usrmerge
>   apt-get install ksh
While this would be inconvenient for whoever tries to do it, I do not 
believe that it justifies declaring merged-/usr so much broken to be 
unsuitable for a release.

> yp-tools (no bug report?)
I missed that it was fixed long ago, I am updating usrmerge.

> What is the status of "dpkg -S" with merged /usr ?
I understand that other people are working on improving it, but I think 
that this is only a cosmetic issue.

> a) testing that all packages in stretch can be installed and uninstalled
I think that somebody did it recently: this is how they discovered that 
the xfslibs-dev NMU was lost.

> b) automated testing that there are no problems caused by /bin/foo and 
>    /usr/bin/foo shipped in different packages
I do this by periodically analysing the Contents files in the archive.

> c) testing that the Conflicts of usrmerge cover all packages in jessie
>    that must be upgraded when installing the usrmerge package 
See above.

> d) searching for packages in previous releases that are no longer in
>    stretch and that break usrmerge, to have them added to the usrmerge 
>    Conflicts
Since I have been working on this for almost three years now I am 
confident that I have covered packages in both wheezy and jessie.

> After reading the wiki page I still don't understand what actual benefit
> merged /usr brings that could make me recommend it to a user.
Then maybe you should read more carefully the provided references (and 
find out that it really depends on how you define "user" here).

-- 
ciao,
Marco

Attachment: signature.asc
Description: PGP signature

Reply via email to