Francisco GarcÃa RodrÃguez <public%francisco-garcia.net@localhost> writes: > However am still not very convinced about having the whole package > tree ( I do not use biology, games, finance...). It seems to me that > the whole thing (cvs, pkgfind, pkg_leaves, pkgsurvey...) will slow > down the larger the tree is. It is very tempting trying to speed > things up selecting a reduced set of directories and/or downloading > only missing dependencies. You can do this, but you're fighting the way pkgsrc is designed to work - just be aware of that and on the lookout for trouble. Any package that has a dependency just includes ../../category/package/buildlink3.mk and expects that to be there. If you get a subset of pkgsrc, and never build a package that depends on something you don't have, you probably won't have a lot of trouble. So removing biology might be ok, because there are likely few packages not in biology that depend on something in biology. But there are not a lot of categories so self-contained, and I think you will find you can only save 10-20% this way. I find that cvs update takes a while, especially on slow machines without a lot of memory (I'm currently updating on a Sparc Classic with 32M of RAM and 4G disk). But I just start it and come back later (4 hours later in this case). I have many other things to do and I'd rather minimize brain time than system time. I guess that if you try to speed up cvs by subsetting that you will end up spending more time coping with not having a full checkout than you will save. But I could be wrong and you could end up with a useful scheme. To really get speedup, I would try writing something that takes a package and checks for including files that aren't there, and then fetches those things. So you'd get /usr/pkgsrc/Makefile and all of /usr/pkgsrc/mk and pkgtools, and then grab the package you want and have the tool get sources for all the dependencies. (Well, I wouldn't try, but that's my advice if you do.)
Attachment:
pgpESkFqHXZAi.pgp
Description: PGP signature