hello.
i do a lot of emerging and unemerging on my gentoo because of testing and looking for
usefull new software.
i am using uninstall script from gentoo-forum. i am not portage- & emerge- tech geek
but this script does not work for me well. i.e. i am sure that when rox was installed
on system it required some additional packages to install before (e.g.
shared-mime-info) and till now no other application needs this shared-mime-info
package to work properly. because my memmory can get me tricky i tried sth like that
several times:
emerge some-packet
-> [several packets were emerged additionaly, for example let it be 5]
$HOME/sbin/uninstall some-packet
-> gives less than 5 packets that can be unemerged.
second thing. this script takes usually a lot of time to find out interesting to us
informations. i do not really understand why it is like that. to be honest i haven't
even analyse it [yeah i'm lasy] to much but i thought about sth like that:
why not prepare such a imo trivial to implement and
fast solution.
let there be such a file somewhere in /usr/portage in the format of:
|packet-name quantity
|packet-name quantity
|...
let it be /usr/portage/deps
when some packed is emerged directly via #emerge packet-name it lands
in this file whith value -1, but when #emerge
other-packet-name just depends on some packet:
1) which is not installed, the line with this packet name with value 1 is
added.
2) which has been installed as dependency of another one [i mean cat
/usr/portage/deps | grep packet-name gives true] its
quantity in this deps file is increased by one.
there probably should be second file with information for each
packet installed on system showing names of ebuild that were merged
in order to install it.
when we want uninstall packet with dependencies we should be able to do it
like that:
#emerge unmerge --with-deps packet-name
the algorithm could be as follows:
1) extract deps of packet-name
2) for each of them check its quantity in /usr/portage/deps if
it's >1 decrease when -1 do not touch only inform [its because that this
packet was installed directly we do not to
automaticly unmerge it] when 0 do same as this shell command
would do:
#emerge unmerge --with-deps packet-name
What do u think about that? Has someone commited sth like this as a patch to portage
or sth? Is there the thing that makes this solution useless, needless & stupid?
I would probably try to implement in kind of scripting language like perl an
"interface to emerge/unmerge basing on this solution this night
and test if it works well.
Cheers,
Marcin `babun` Daczkowski
PS: the intention of this email was diffrent at the begining. but now it should post
it to -devel - heh, but i'm not even subscribed ;> [lazyness again]
--
[EMAIL PROTECTED] mailing list
