[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: incapable and obsolete APT / Aptitude replacement




 > Od: jackyf.devel@gmail.com
 > Komu: kc.ubuntu.cz@centrum.cz
 > CC: debian-devel@lists.debian.org,  APT Development Team 
 > Datum: 09.02.2009 14:20
 > Předmět: Re: incapable and obsolete APT / Aptitude replacement
 #> As a SUSE user, I'm used to work with Zypper/Libzypp package managementm using SAT solver. Since Opensuse 11.0, Libzypp is the best, fastest and te most powerfool tool to solve dependenies ever used in #Linux distribution. 
 #Please, no much advertises here. SUSE goes its own way, and Debian has large
 #own specific needs and particularities.

It was not meant as an advertisement. I would be pleasedto have some of theese tools in Debian.

 #>  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

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.

 #> I made some personal test, to compare the solver capabilities myself. I add KDE 4.2 repository to SUSE and Ubuntu, and made an upgrade from 4.1.3 to 4.2. After that i disabled KDE 4.2 repositories and delete #one of the KDE 4.2 packages. This lead to inconsistent state, because KDE 4.2 repository was unavailable to repaire the dependency. The solution is obvious. Donwgrade somepackages back to KDE 4.1.3, to make dependencies OK because all 4.1.3 packages are available. 
 #You might forgot that in the Debian way downgrade is unsupported at all, so
 #APT treats the downgrade as one of worst possible solutions.

Oh. I really did not know that. I have to keep it in mind for the future instalations.

 #> For APT (ubuntu), it was totaly imposible to find that existing solution. It gave it up because of broken dependencies. No parameters like "-f" worked. After that, I tried SMART, which solved the problem #immediatelly. As I posted above, Smart has far better dependency solver. 
 #> After that, I made the same situation using Zypper/Opensuse. It immediately found that existing solution as the fastest and with minimum changes, but offered me some other possibilities. 
 #> So. APT is totally incapable to solve dependency problems and from mathematical point of view find only only obvious predictable solution. If it does not available, or package dependencies are written badly, it #ends without solution. 
 #Mathematical point of view is something that does not value high in package
 #management (at least, for me and some people). The package manager should have
 #to deal with real problems on real distro in the first place, and APT is
 #playing this role quite well (though can do it better, of course).

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?

 #> Smart is far more better and Zypper is the best. In addition, both SMART and Zypper has ability to manage repositories and keys, which APT is unable. (you have to dit souces.list manualy) 
 ##> Is there any chance to implement better solvers to APT/Aptitude, chagne them to multiplatform and far better SMART or porting the best Zypper tool from Opensuse?

#APT team has a number of tasks to work. As usually, patches are usually welcome.
 #I obviously think that "incapable and obsolete" (from subject of the letter)
 #aren't the words which can characterize APT.
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.

Thank you a lot for your response.

Reply to: