Luca Bruno <lu...@debian.org> writes: > On Wednesday 03 December 2014 18:21:08 Ryan Tandy wrote: > >> On Wed, Dec 03, 2014 at 11:40:24PM +0100, Ferenc Wagner wrote: >> >>> I got pre-approval on #771962: the upload will be unblocked, provided >>> it's in unstable by Monday the 8th of December. People with upload >>> rights, if you can spare a minute please review the above change and >>> consider sponsoring the upload! Actually, review is welcome from >>> anybody. :) >> >> Thanks very much for working on this, and the debdiff looks fine (but I >> haven't actually built or tested it). I hope you can find a sponsor in >> time. Luca, are you reading? > > I was following the discussion, and I have to say that I am not too > comfortable in uploading this NMU at this point of the release cycle. > So NACK on my side. > > My main concerns are: > * I am not sure that I grok all the implications of that. I suspect that > most of our (overly) complex pre/postinst scripts makes some assumption on > schema/db consistency, at least implicitly.
I went through all the maintainer scripts in the package, and did not find any dependency on DB consistency, apart from the config DB itself, which we touch on the filesystem (which is unsupported). And of course apart from the current issue, which is assuming that slapadd will work on the result of slapcat. This is false without the -s option. > * We are changing the default behavior to fix a single-case situation, by > removing a safety check. Mmmh... As you point out below, debconf does not offer switching off schema checking. Just like it does not offer configuring replication. Thus if a database is not schema-correct, that must be the result of manual configuration, not some default behavior. From this point of view, we do not change the default behavior, we extend it to other cases. If the database was schema-correct, it will stay so. If the admin uses a config where it wasn't, then it will stay so as well. > * This bug has been open since some time, never marked as RC, put on > low-priority by the maintainer I don't understand why. This bug breaks upgrades, and the only workaround I know of is manually editing the postinst script. > and upstream discouraged dropping the "-s". (I guess you mean "using"). Yes, but I think their reasoning about importing invalid databases does not apply in our case, see above and below. > * This is not even the proper solution, just a quick-hack patch. The "proper" solution would require separate dump/restore decisions for each database, and we haven't yet got the infrastructure for that. And it would only achieve not using the -s flag when it wouldn't have any effect anyway (maybe apart from slowing down the import). After all, we're loading dumps we ourselves made a couple of moments earlier, not some synthetic data. > Moreover, I don't consider myself an LDAP expert, but I have some comments on > the issue: > * I would say that requiring/checking schema integrity across upgrade is a > good general measure, and we should NOT work around that. Fail early, fail > loudly. My point here is that schema-correctness has nothing to do with the upgrade, as the schema is just a part of the local configuration, which is not changed by the upgrade. > * IIRC disabling schemachecking is heavily discouraged. We don't offer that > option in debconf. I assume the admin are really aware of the setup, and > know its quirk. As far as I know, it's not only discouraged, but is actually impossible for some time now. The only way to switch off schema checking is using replication, making your database a read-only shadow. > * Workarounds for the specific corner case exists, but maybe are a bit > undocumented. I don't consider editing the postinst script a viable workaround. Maybe I miss something here? Disabling dumping does not cut it, see #770827 and #771823. > So my alternative suggestion is: let's make it explicit that we value schema > integrity, and we rely on it across upgrades OpenLDAP also values schema-correctness (see above), and that's why artifically relying on it does not really help, only needlessly breaks upgrades on partial replicas. > let's put a point in the release notes to document how to workaround > this partial replica scenario; let's try to address this better in the > next point release. I honestly don't think there's much to gain in that direction. Unless there really is a good workaround (not involving hand-editing maintainer scripts during the upgrade), I find it an unneeded burden on the user. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oarjo98z....@lant.ki.iif.hu
