Re: incapable and obsolete APT / Aptitude replacement
>> Od: firstname.lastname@example.org Komu: email@example.com CC:
>> firstname.lastname@example.org, email@example.com Datum:
>> 09.02.2009 18:15 Předmět: Re: incapable and obsolete APT / Aptitude
> firstname.lastname@example.org wrote: #> #> If you look at the comparison
> i posted above, you can se that APT is worse than Urpmi and SMART -
> which was the best dependency solver in that comparison. Zypper
> mentioned above, is a ittle bit better #than #smart: #> #> #> #If
> you look at users' feelings, situation will rotate significantly, due
> to my #> #experience. #> #> That's completely nonsense. Possitive
> rating targets the APT-DEB-debian repository complete system. It does
> not mean, APT it-self is good. It can be worst all-over the world,
> but usage among single repository #with dependencies tested for years
> before release can't challenge hard solver work. #That's almost
> completely not true. Debian release managers and maintainers of #key
> system packages may tell you how much efforts they put to allow
> smooth and #painless upgrades of the system.
> This is exactly what i want to say. Debian developers do great job
> and long hard work, and in the end, as a result original Debian
> repository exist, with so precisely descibed dependencies, that even
> the most stupid package manager could work well. That is not a
> challenge for dependecy solver. Solving preblems among the debian
> repository is easy.
> This Debian aproach is great for servers, but not usefull for
> Desktops, where bleeding edge software and mixed repositories could
> be expected. That the real reason of bigy hype around Ubuntu Linux,
> which fill the hole for Debian Desktop. And in that case, I feel APT
> useless. And because Debian and ubuntu are bound together I think it
> is imposible to make a change only in ubuntu. Although they put some
> effort and money in SMART.
> #> As you pointed above, and as I understand it, APT is de-facto
> simple package-updater. Mixing many repositories or downgrading is
> treated as a stupid way. Am I right? #Mixing many repos? Not, of
> course. I see sources.list's with dozen of repos. #Downgrading
> packages may break your system (by design, in any software). So, #all
> downgrades should be done with caution and in not-automatic way.
> That is not the argument. How could APT know, which souliton is the
> best. As I said above, on Debian Stable, it can be expected that
> upgrading is the only way. But not on the desktop whith shiny new
> #> OK. Maybe i just supposed APT to do various things I'm used to
> expect from other package managements. Now i undrstand, reading the
> point of view of APT ?cotributor?, this piece of software is not for
> me. #Maybe.
> But still, there is a qeustion, If I use Debian-like system, which
> package manager with powerfull solver I can use? Package management
> is not the only argument for choosing or refusing some distribution.
[you mail are not very readable: you should learn to write good
text only email]
You look the problem in a (IMO) completely wrong way.
You insist about the solver, but ... if you want to solve dependencies
mathematically, you should do the right assumptions.
Packages are normally done chronologically with an incremental version
(with very few exceptions). When people do a package, they don't know
about future version of dependencies, and it is nearly never updated,
so there is an asymmetry on dependency declaration. BTW we care about
much more last versions.
So, I think you did the wrong assumption: dependencies are correct
both ways. Instead, apt known that a older version could have wrong
dependencies (missing upper limit), thus the downgrading is avoided.
If you want to improve dependency solver, you should firstly build a
tool that generate automatically the dependencies (thus also
between old package and newer dependencies). Only when you are sure
about correctness of dependencies you could try to improve the solver
in a mathematically correct way.
Debian is improving such part, with automatically symbol versioning,
but .. it is very difficult. Impossible to generate a totally correct
As example: it could be impossible to distinguish
automatically which bug (in a library) is need to a program (wrong
assumption of programmer), and which bug need to be corrected, (which
correct also the program).
Without correct dependencies, don't try to test formally the solvers,
instead try real cases and check the heuristic of various solvers).
BTW Debian try to solve the your second point being the biggest
distribution: thus needing less external package.
BTW, in my experience, the external packages, in small repository have
always wrong dependencies (try-error method, instead of code analysis
[linker arguments, modules, ...]), thus a exact solver don't
solve the problem.
Heuristic is still the right way to solve package dependencies!