Re: apt questions
On Wed, 13 Sep 2000, Alfredo Kengi Kojima wrote:
> On Wed, 13 Sep 2000, Jason Gunthorpe wrote:
>
> > Why did you make this bunch of changes:
> >
> > - if (Cache[J->Pkg].Install()) {
> > - if (Debug == true)
> > - clog << " Fixing " << I.Name() << " via keep of
> > " << J->Pkg.Name() << endl;
> > - Cache.MarkKeep(J->Pkg);
> > - } else {
> > - if (Debug == true)
> > - clog << " Fixing " << I.Name() << " via install
> > of " << J->Pkg.Name() << endl;
> > - Cache.MarkInstall(J->Pkg, true);
> > - }
> > + if (Debug == true)
> > + clog << " Fixing " << I.Name() << " via keep of " <<
> > J->Pkg.Name() << endl;
> > + Cache.MarkKeep(J->Pkg);
> >
>
> It seemed to me that if a package is not already marked for installation,
> doing a MarkKeep() on it won't change that. Since we need the package
> that satisfies the dependency benig handled to get installed, that code
> marks it for installation if it's not yet installed in the user's box.
Hurm. The purpose of the KillList is to remove packages that are
interfering - in a delayed fashion just in case the situation is resolved
by removing the package itself. Making it do installs gives me a bad
feeling - I suspect you will either end up with unrequested packages in
some cases or, unsolved solutions in others (it will loop between adding
and removing a set of packages and give up) -- I don't know, that is not
something I've ever really thought to try.
The entire basis of operation for this algorithm initially was purely a
removal algorithim. It started with a set of packages that was larger that
necessary and selectively cut it down till everything was OK.
A problem with provides is that MarkInstall does not really properly
select a providing pacakge when it does it's first jab at the install, so
when the problem resolver gets called it cannot solve that problem soley
via removes.
The code you see to install new packages is a bit of an add on. It proved
necessary in some cases to pull the approximation out of a hole and yeild
a better result. Installs are primarily focused around protected packages
and packages whos reason for being removed has also been removed..
I need to look at my CVS logs in detail to explain this one though:
{
if (BrokenFix == false || DoUpgrade(I) == false)
{
// Consider other options
if (InOr == false)
Not sure *what* that DoUpgrade is doing there.
About your other change..
After closer inspection I see now that the reason for the VList was
primarily motivated by conflicts. The intention was to get rid of all
conflicting packages, so having the algorithm exit once it solves a
non-conflicts (by keep/remove of the problem package - not the dep!) is
correct.
[
Aside: If you start by installing all packages you are interested in and
then installing all their dependencies - what will be the major problem
with the resulting set? The answer it turns out is primarily conficts and
'conflicts' due to unmet versioning. Since the depends are all met you
have to cut stuff away to advoid all the conflicts that exist - this was
the original (years and years ago) motivation of this routine
]
Basically, by this point it is trying to decide which of the two packages
involved in the dependency get kept/removed.
I think, given what you have explained, you should be able to do
apt-get install <some package using libncurses4> <some package using 5>
And have it properly get both - this is because the Protected feature
triggers this code:
// Try a little harder to fix protected packages..
if ((Flags[I->ID] & Protected) == Protected)
{
if (DoUpgrade(Pkg) == true)
{
Scores[Pkg->ID] = Scores[I->ID];
break;
}
[pkg in this instance will be the ncurses]
....
Overall I think you are best to explore making MarkInstall work better in
the case of provides (particularly single provides). That is not a common
situation in Debian - it is underdeveloped and it would be safe to improve
that area, and it should yeild the right result.
If that fails.. Then we must explore enhancing the resolver to better
handle OR group'd packages. The fact that it handles OR groups at all was
only added in the last year or so, and I'm sure it can be done better.
Ideally an entirely better mechanism is needed to deal with this.. But I'm
not so sure what a good direction would even be to start building a
replacement. Though, I have often wanted to explore the possibility of
using a flow type algorithm - that might work better.
Jason
Reply to: