On Mon, Jan 21, 2019 at 08:43:32AM +0900, Hideki Yamane wrote: > On Sat, 19 Jan 2019 10:58:08 +0100 > Julian Andres Klode <jak@debian.org> wrote: > > We can't. Even if we added a reverse Recommends, we are still missing > > support for a logical and. There is no interest in adding that as our > > dependencies are already too complex. > > And just a question, rpm people use libsolv for package dependency > resolutions, is there any assessment plan for it? If that question is targeted at if we will adopt libsolv in apt, then the answer is likely never, but don't worry, because we have better solutions which already exist and others are jealous of. apt tools provide a way to talk to external resolvers allowing to experiment with new and improved ways of solving dependencies without throwing away the entire ecosystem around it (which is kinda what happened with the yum → dnf move and is to be expected again for dnf → <future>). The key takeaway in this is that simple SAT solving isn't the holy grail that a casual look suggests: A SAT solver e.g. has no qualms about installing 'ed' as text editor in favor of your beloved vim/emacs as long as it is a valid solution. If you are into playing try installing 'aspcud'. Julian is e.g. playing with another idea at apt-solver-kalel (see salsa). They are slower due to the pluggable architecture, but that can be solved if need be – for now they do their work just fine in various contexts (e.g. buildds). Back to the original topic of complex dependencies: I don't think they are a good idea exactly due to their complexity – for many maintainers the difference between Depends/Recommends/Suggests/Enhances seems already too complex and many users want to reason about them, too! The point forward here will likely be … wait for it … improved solvers (or perhaps apt hooks resulting in a sort-of solver chain) making much more use of the data we have available (I say we as in Debian as it is far from usual to have screenshots, tags and even l10n teams!). You mention language packs: Sure, a maintainer can try to express this via hardcoded dependencies, but in the end its the user who should be on the deciding end of which language pack(s) to install. Thankfully the language packs not only have a rather predictable naming scheme, they also come with debtags identifying them as packages providing certain l10n and i18n elements which could potentially allow a user to configure a solver to install l10n & i18n packs for individuals culturally from Antarctica, but most proficient in Klingon currently residing on Mars – good luck expressing this via Supplements or deps in general. That applies to many more areas as well like (not) working with scanners/printers/… if the user does not have that hardware and so on. As usual, there is no shortage of ideas, but a shortage of people actually working on them all (or, for that matter, just a few). Best regards David Kalnischkies, who implemented the pluggable solver thing and is therefore potentially hopelessly biased.
Attachment:
signature.asc
Description: PGP signature