On Sat, 23 Jul 2016 15:38:26 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jul 2016 17:23:48 +0300 > Andrew Savchenko <[email protected]> wrote: > > On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote: > > > On Fri, 22 Jul 2016 16:41:56 +0300 > > > Andrew Savchenko <[email protected]> wrote: > > [...] > > > > I see no point in trashing ebuilds with dead code that will never > > > > be used. Though if there will be a PMS or eclass function with > > > > "proper" implementation, I don't mind, since extra code will be > > > > moved from ebuild elsewhere. > > > > > > Slots are not the only way in which you can end up with multiple > > > installed versions of the same package. Another way is if there's a > > > fatal error during certain parts of the upgrade process. > > > > If setup is broken to the point when several version within single > > slot are installed (or are reported to be installed), then: > > > > 1) There is no way to tell which version is valid and all of them > > may be invalid. That's why REPLACING_VERSIONS is of no use at all > > in such situation. > > > > 2) System is severely broken and mistakenly shown (or not shown) > > ewarn message will be the least problem for a user of such system. > > Uh, nope. The PM can recover from that situation, so long as people > don't go around writing broken ebuilds that make unwarranted > assumptions that the spec specifically tells them not to make. Don't > get into the habit of writing broken code.
Oh, nice: strictly follow PMS no matter what, right? Then let me remind you that not so long time ago I advocated for strictly following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3]. But I was _enforced_ by QA to _violate_ PMS and remove the valid syntax blocks [4]. This decision was made because of $reasons: - we lack ||= operator; - || ( := ) behaviour is not implemented properly in existing PM; - "it doesn't make *any* sense"; - other valid and unquestionable $reasons ... So the result is that common sense and practical considerations take over PMS. And what we have in the REPLACING_VERSIONS case? It doesn't matter that such situation never happened and will likely never happen, but one must follow PMS strictly no matter what. Such attitude is not fair at least. > Or to put it another way: you are wrong, and you don't know enough > about the situation to understand why you're wrong, and you clearly > have no interest in learning, so just do as you're told. I don't deny that I may be wrong on this matter, but I demand a proof, an experimental one. And I see no such proof, only theoretical considerations without any practical confirmation. Do we ever had such case like multiple versions of the same single-slotted package installed or recorded as installed in the real world? I'm not sure even in this, but I may assume that it may happen one day. Do we have any proof that PM can recover from such situation, where VDB is a mess and installed files can also be a mess? I'm not sure in this at all. Do we have any test suits for portage (as the most popular PM implementation) for such cases? I doubt this, I can find none. I'm not sure if such tests are implemented in other PM test suits too. [1] https://archives.gentoo.org/gentoo-dev/message/abd0c82b058aa0109c12050ae837fba0 [2] https://bugs.gentoo.org/show_bug.cgi?id=586238#c1 [3] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-780008.2 [4] https://bugs.gentoo.org/show_bug.cgi?id=586326 Best regards, Andrew Savchenko
pgpe7YIXYhr4n.pgp
Description: PGP signature
