On Thu, Jun 21, 2018 at 06:55:54PM +0200, Mikolaj Izdebski wrote: > On 06/21/2018 06:26 PM, Stephen Gallagher wrote: > >>> So, when we started looking at ways to provide alternative software, we > >>> determined that parallel-installation was a non-goal. Not needing to > >> solve > >>> an unsolvable problem meant that we could focus on the parts that really > >>> matter: allowing people to select which single version of the software > >>> meets their needs. > >> > >> So the conclusion is that inability to have parallel-installable streams > >> of the same module is not due to technical difficulties to implement > >> that feature, but rather a consequence of prioritizing different > >> requirements. > >> > >> > > You drew a conclusion that is EXACTLY the opposite of what I said above. We > > determined that parallel-installation was basically impossible to build in > > a generic way. Once that was eliminated as a possible requirement, the rest > > fell into place fairly neatly. > > Allowing parallel installation of two distinct package sets, provided > that they don't conflict in any way - how is that impossible? I get > that it's not a goal for modularity to support this, but I don't see any > technical reason not to allow it. If those package sets are completely distinct, most of the arguments Stephen provided indeed don't apply, however, you still need to thoroughly check that your module and all of its dependencies are installable in this scenario and you need to be able to do that in the buildroot as well. That includes both modular and ursine buildroot. Furthermore you need to come up with a new tracking mechanism in the software database as well as usable UI and APIs. All this for only a small set of modules that could easily delivery via some other method. A generic solution appears to be impossible. This kind of a limited solution can be done but as I said earlier, it's not currently on the agenda. P
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/JMDBJKW2JXPAGLDJKBCAOW5AKYIKXEFM/
