On 18/06/2015 16:57, Hendrik Boom wrote:
I assume that aptitude has enough algorithmic capacity to do this, but when things get complicated there may not be enough computational power to carry out this analysis in available time and space.
My experience is that we have waaaaay more computational power than we think, and most inefficiencies come from the implementation, not the amount of work there is to perform. I'm working on a dependency manager. At some point, I have to do some operation in O(n^2), n being the number of services; there's no other choice. But it's still blazingly fast, and you can have up to thousands of services with sub-second execution times. Modern computers are powerful, and data size is nothing to be afraid of - as opposed to program size, which must be handled by humans. So, yeah, if aptitude can handle package dependencies, just feed it, make it work. Even if you have disjunctions - and disjunctions are algorithmically expensive - it's not what will take the most time. Unless, of course, the engine is written in Python or something equally unsuited.
Bow, since its possible to have seeral init systems installedd, and even to have different subsytems started by different init systems (not all running as PID 1, of course), perhaps the mutual exclusion among the init systems is a bad idea.
Absolutely. Why enforce exclusion when you can have a choice ? Make a "currently active" vs. "inactive" switch, I don't know the Debian/Devuan terminology, and allow users to install both.
But I can't recommend this be done for davuan jessie. Too soon, and it would make jessie too late.
I think we're all planning for the future, here - get Jessie out first, and then small steps, one at a time. :) -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng