On Wednesday 10 September 2003 19:13, Marcin Daczkowski wrote: > 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? > > 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]
This is a very good idea. This is a very good idea. Having a refcount on each package would increase performance somewhat. You'd still have to check for deps on each package down the tree, but that's better than looking at all packages. The only problem would be if the refcounts got out of sync for any reason, but having a rebuild-deps command would counter that. You should post this on -dev! Jason -- [EMAIL PROTECTED] mailing list
