On 24 June 2012 05:16, Alec Warner <anta...@gentoo.org> wrote: >> >> That's covered in the devmanual and in the user documentation, so >> there's no need to repeat it here. > > http://devmanual.gentoo.org/general-concepts/slotting/index.html > http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies > > I don't think the documentation forbids what these developers are > doing. I think you implemented a nice heuristic for your users in your > resolver that used to work because slots had a typical set of users > cases and the heuristic performed well in those cases. > > Now people are occasionally using slots in a different way and your > heuristic penalizes those cases. That sucks, but you might have to > actually change your resolver because I don't think 'funky-slots' > properties is going to garner much adoption. It just appears that the > heuristic you used to use isn't helpful anymore (or has too any false > positives, or whatever.) >
It seems to me that the defacto understanding of slots is that given 2 slots for one package, one slot will be a natural upgrade from another competing slot, assuming a slot that is a version progression. This makes sense for most packages. However, it seems slots are in some cases being used for purposes other than natural version progressions, and representing siblings instead of child/parent , and in such case, its not logical to want to install a different sibling simply for having a different sibling installed. So the request is to have some sort of metadata to optionally convey the intent of what the slot "means", where the defacto method would be "They're versions, if X > Y then X is a natural upgrade from Y, and is slotted for transition and similar reasons" , which would indicate to UA's that if they have Y, and X becomes available, that they will want to install X. And there would be the alternative(s), "Funky slots" , where slots DONT indicate version progression, and so should *not* be 'upgraded' to from alternative slots. Logical place to store such information to me seems <metadata.xml> -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
