On 24 June 2012 05:16, Alec Warner <firstname.lastname@example.org> wrote:
>> That's covered in the devmanual and in the user documentation, so
>> there's no need to repeat it here.
> 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
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>
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"