Portage auto-removal feature

Message

lxnay · Post by **lxnay** » Mon Oct 09, 2006 10:03 am

is there an option that auto-removes blocked packages?
For example, when I switch from kde (monolithic) to kde-meta (meta packages). Should be fine if portage automatically removes the blockers and then install the kde-meta packages.

Why not? Just an option, not a behavior. We I work on apt-based distros, apt works in this way.

cokey · Post by **cokey** » Mon Oct 09, 2006 10:58 am

lxnay wrote:is there an option that auto-removes blocked packages?
For example, when I switch from kde (monolithic) to kde-meta (meta packages). Should be fine if portage automatically removes the blockers and then install the kde-meta packages.

Why not? Just an option, not a behavior. We I work on apt-based distros, apt works in this way.

It can't remove them because they are semi-circular dependencies. The packages that are blocked are needed and so are the blockers, the only thing portage can do is offer you a choice of which one to keep.

If portage was to make a choice then there would be b0rkages in roughly 50% of the cases where it happened. Anyway, thats why we have -p or --pretend

lxnay · Post by **lxnay** » Mon Oct 09, 2006 12:09 pm

Yes but I think that Portage does not scale in this area if compared to apt just for this matter. It's hard to work on a Upgrader that compares the installed packages of two gentoo installations.

cokey · Post by **cokey** » Mon Oct 09, 2006 12:48 pm

lxnay wrote:Yes but I think that Portage does not scale in this area if compared to apt just for this matter. It's hard to work on a Upgrader that compares the installed packages of two gentoo installations.

but apt has the luxury of programs not being *specifically* compiled against others and their versions.

With gentoo the packages are raw, as in respect of the fact that they are completely untouched and not patched. Apt packages are specifically compiled for the debian based system that they will be deployed on, Gentoo's package manager is designed to take base packages and tailor them to the system.

It is a completely different way of managing packages

Genone · Post by **Genone** » Mon Oct 09, 2006 3:34 pm

Well, Zac has just added a new feature to portages dep resolver to avoid some of the more stupid blockers (those where an update of a package is enough to get rid of a blocker). But in the general case you can't just randomly remove blockers (in a bidirectional block, which side do you remove? I wouldn't trust a heuristic to decide that)

lxnay · Post by **lxnay** » Mon Oct 09, 2006 3:58 pm

Yes but I take the example of the SabayonLinux Installer Upgrade code (http://svn.sabayonlinux.org). If I'd have a portage option to let it to force blockers removal I won't have to remove every package that is not available on the current live system. It's hard to understand, I make an example:

Live Upgrade system collects the packages on the LiveCD (A) and the packages on the currently installed Gentoo system (B).
The current behavior is:
- first of all to remove the packages that are installed in (B) but not in (A) to avoid system inconsistencies.
- then add the packages that are not installed in (B) from (A).
- then update the packages that are installed in (B) and available in (A) with a different version.
- then check the USE file in /var/db/pkcat/pkgname/ to see if the a package in (A) has been updated keeping the same version (maybe that from a release to another, you add the support for something using new USE flags)
- in the end, check for broken libraries (using a small shell script and "equery belongs").

So, the thing that I'd like to fix, is the removal of the packages that are installed in (B) but not in (A). For example, I install my favorite game "foobar" that does not conflict with anything but gets removed anyway just because it is not installed in (A). With at least a basic capability of handling blockers, I can happily rewrite this part without any dirty hack.

cokey · Post by **cokey** » Mon Oct 09, 2006 11:51 pm

lxnay wrote:Yes but I take the example of the SabayonLinux Installer Upgrade code (http://svn.sabayonlinux.org). If I'd have a portage option to let it to force blockers removal I won't have to remove every package that is not available on the current live system. It's hard to understand, I make an example:

Live Upgrade system collects the packages on the LiveCD (A) and the packages on the currently installed Gentoo system (B).
The current behavior is:
- first of all to remove the packages that are installed in (B) but not in (A) to avoid system inconsistencies.
- then add the packages that are not installed in (B) from (A).
- then update the packages that are installed in (B) and available in (A) with a different version.
- then check the USE file in /var/db/pkcat/pkgname/ to see if the a package in (A) has been updated keeping the same version (maybe that from a release to another, you add the support for something using new USE flags)
- in the end, check for broken libraries (using a small shell script and "equery belongs").

So, the thing that I'd like to fix, is the removal of the packages that are installed in (B) but not in (A). For example, I install my favorite game "foobar" that does not conflict with anything but gets removed anyway just because it is not installed in (A). With at least a basic capability of handling blockers, I can happily rewrite this part without any dirty hack.

So let me get this right, you want to remove all the packages off the gentoo system which are not on the live cd whether they are ugraded or not.

Won't you have some dependency problems after?

Anyway, the best way to visualise this is to take a major blocker like monolithic X vs modular X. How would a package manager know:
a) what version to remove.
b) what deps to remove.
c) if the versioning numbers are different then it would look like a different package.
d) 1 dep could be blocking 10 packages...
e) 10 deps could be blocking 1 package...

Where a deb control file holds depends and pre_depends it also holds a conflicts line which allows apt to do reverse dependency removal - something portage doesn't have, it has to be done manually with -C

cokey · Post by **cokey** » Thu Oct 12, 2006 6:57 am

i have some good new for you, Zac Mendico has said there may be a solution to your needless blockers in the new portage:

portage-2.1.2 [1] has made recent progress. Here are descriptions
of some of the recent changes:

* Profiles support multiple inheritance.
* CONFIG_PROTECT and CONFIG_PROTECT_MASK both support files (not
just directories).
* Collision protection handles symlinks properly.
* Dependencies can be satisfied by installed packages that do not
have matching ebuilds in the portage tree or overlay.
* Emerge automatically ignores blockers that are made irrelevant by
an upgrade.
* Emerge builds a complete dependency graph in order to ensure
correct merge order and detection of circular dependencies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.

What that means is that all your blockers now will be serious ones that cannot be done automatically

Portage auto-removal feature

Portage auto-removal feature

Re: Portage auto-removal feature