On Sun, 24 Jul 2016 00:04:53 +0200 "Andreas K. Huettel" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Freitag, 22. Juli 2016, 15:57:36 schrieb Ciaran McCreesh: > > > > > Wrong. PMS specifically requests you to account for such a > > > > possibility. > > > > > > Common sence must prevail over formal approaches. While PMS is > > > great, it is not perfect in all possible aspects, and this one is > > > one of them. > > [snipping irrelevant blather] > > > 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. > > 1) If a package only ever had one slot, it cannot ever have two versions > installed at the same time. That guarantee (of only ever one slot) can be > given for the portage tree (sic). Obviously it doesn't work for overlays, > but there are many things we don't care about for overlays. [A] > > 2) If a package manager leaves two versions of a non-slotted package > "installed" somehow, that package manager is fundamentally broken and its > author should forever refrain from specifying anything. It's not our job to > work around Paludis failure modes. [B] > > > [A] Let's say there are overlays which package StarOffice, Go-OOO and some > other random OOO fork. Do I have to block them all because of file collisions > then? > > [B] The package manager could be broken to leave some random files on the > system too... maybe we need some more blockers or specific error handling in > all ebuilds? So, to summarize: we should dump PMS and get back to caring only what Portage seems to do for a few developers with big mouths, because adding a single 'for' loop is so complex you can't handle it? Instead you prefer wasting hours of time of others to discuss ignoring the specification rather than doing things properly. If you don't like PMS, start the procedure for changing it. Or dump it altogether. But stop this nonsense of 'we use this spec that was written specifically for us but random developers can ignore random points because they can'. -- Best regards, Michał Górny