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

Re: APT 0.7 for sid

On Wed, Jun 06, 2007 at 09:49:00PM -0400, Joey Hess wrote:
> Michael Vogt wrote:
> > - support for the new dpkg "Breaks" field (thanks to Ian Jackson for
> >   his work on this)
> Although dpkg still doesn't have Breaks support, so we still can't use
> it, AFAIK..

In this case apt will be ready for it when dpkg gets it :)
> > - automatic installation of recommends like aptitude
> I want to check how this will affect d-i. The Recommends tree is still
> fairly hairy/unrefined and can result in a lot of crud being pulled in.
> (See #388290. Though having them installed by default would certianly
> add pressure to fix the bogus ones.) 

We can decide to disable the feature for now until the recommends tree
is cleaned up or just turn it off in the install
(--no-install-recommends) I personally think the only option we have
is to turn it on because otherwise the sitution will not change. But
we do not have to do it just now, we can set a date for this so that
there is enough time. 

If you are curious what would be installed with recommends turned on,
you can run (with the new apt or the apt in experimental):

# apt-get install --install-recommends --fix-policy 

to find out what package pulls in what recommend, use:

# apt-get install --install-recommends --fix-policy -o Debug::pkgDepCache::AutoInstall=true

> Two scenarios I'm interested in:
> 1. If tasksel runs aptitude --without-recommends, will that be enough to 
>    avoid recommends still, or will an additonal flag now be needed?

Currently both would be needed, but I hope that we can fix that so
that aptitude use the same internal variable as apt

> 2. Will the many parts of d-i that run apt-get -y install <foo> need to
>    be changed to pass some sort of flag to avoid pulling in recommends?

If we decide to turn it on then you will need to pass
"--on-install-recommends" or set "APT::Install-Recommends=false" in a
config file.


Reply to: